MySQL TPS Capacity Benchmarks by Server Specs: From 4-Core to 64-Core Reference Guide

TPS vs QPS Definition

TPS (Transactions Per Second) measures completed transactions per second. In databases, one transaction may contain multiple SQL statements, so TPS does not equal QPS. If a transaction has only one SQL, TPS ≈ QPS; if it has multiple SQLs, TPS is typically lower than QPS.

Concrete Transaction Example: Order Placement

A single order transaction comprises four operations wrapped in one atomic unit:

Decrement inventory: UPDATE stock SET num = num - 1 WHERE goods_id = 101; Create order record: INSERT INTO orders (order_id, user_id, price) VALUES (...); Write audit log: INSERT INTO log (action, time) VALUES (...); Commit: COMMIT; The entire sequence counts as 1 transaction for TPS measurement.

MySQL TPS Reference Ranges by Hardware Spec

The author provides a conservative estimation for typical OLTP workloads:

4-core / 8 GB : 1,000 – 5,000 TPS

8-core / 16 GB : 3,000 – 10,000 TPS

16-core / 32 GB : 5,000 – 20,000 TPS

32-core / 64 GB : 10,000 – 30,000 TPS

64-core and above : 20,000 – 50,000+ TPS

Practical Estimation Guidelines

For ordinary business, assume a single MySQL instance handles 1,000–5,000 TPS as a conservative baseline.

Well-tuned, high-spec single nodes can reach 5,000–20,000 TPS .

When sustained write throughput exceeds 10,000 TPS , the author advises against relying solely on vertical scaling. Instead, evaluate: sharding (分库分表), caching layers, message queues for async processing, and hotspot splitting.

Reasoning Chain

The article moves from definition (TPS vs QPS) → concrete multi-SQL transaction illustration → hardware-dependent benchmark ranges → capacity planning rules of thumb → architectural pivot point at 10k TPS where horizontal strategies become necessary. The numbers serve as reference anchors, not guarantees, and the final recommendation emphasizes system-level design over hardware upgrades alone.