How Much Concurrency Can MySQL Handle? A Practical Breakdown

Definition of MySQL concurrency

MySQL concurrency measures how many requests the server can handle in a unit of time, typically expressed as QPS (queries per second) for individual SQL statements and TPS (transactions per second) for committed transactions.

Basic calculation examples

SELECT * FROM user WHERE id=1;

Executing the statement 10,000 times yields QPS = 10,000.

BEGIN;
UPDATE account SET money=money-100;
UPDATE account SET money=money+100;
COMMIT;

Executing the transaction 1,000 times yields TPS = 1,000.

Factors that determine achievable QPS/TPS

SQL complexity (simple point look‑ups vs. complex joins)

CPU and I/O capacity of the host

Quality of indexes (index hit rate, selectivity)

Transaction design (size, lock duration, isolation level)

Hardware specifications such as number of CPU cores and amount of memory

Typical single‑node capacity by workload scenario

Simple point queries with good index hits – several thousand QPS; on high‑end hardware the number can be higher.

Mixed read/write workloads (ordinary business logic) – around 1 k–2 k QPS is common.

Complex SQL, heavy transactions, noticeable lock contention – bottlenecks often appear at a few hundred QPS.

Practical observations

If the workload consists of simple reads with effective indexing, a well‑configured single MySQL instance can sustain a few thousand QPS, sometimes exceeding that figure on strong hardware.

When reads and writes are mixed, transactions are heavy, indexes are sub‑optimal, or hotspots exist, the system may start to strain at roughly one to two thousand QPS.