Small Datum: Using sysbench to measure how MySQL performance changes over time, November 2025 edition

This has results for the sysbench benchmark on a small and big server for MySQL versions 5.6 through 9.5. The good news is that the arrival rate of performance regressions has mostly stopped as of 8.0.43. The bad news is that there were large regressions from 5.6 through 8.0.

tl;dr for low-concurrency tests

for point queries

MySQL 5.7.44 gets about 10% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51

for range queries without aggregation

MySQL 5.7.44 gets about 15% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51

for range queries with aggregation

MySQL 5.7.44 is faster than 5.6.51 for two tests, as fast for one and gets about 15% less QPS for the other five
MySQL 8.0 to 9.5 are faster than 5.6.51 for one test, as fast for one and get about 30% less QPS for the other six

for writes

MySQL 5.7.44 gets between 10% and 20% less QPS than 5.6.51 for most tests
MySQL 8.0 to 9.5 get between 40% to 50% less QPS than 5.6.51 for most tests

tl;dr for high-concurrency tests

for point queries

for most tests MySQL 5.7 to 9.5 get at least 1.5X more QPS than 5.6.51
for tests that use secondary indexes MySQL 5.7 to 9.5 get about 25% less QPS than 5.6.51

for range queries without aggregation

MySQL 5.7.44 gets about 10% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51

for range queries with aggregation

MySQL 5.7.44 is faster than 5.6.51 for six tests, as fast for one test and gets about 20% less QPS for one test
MySQL 8.0 to 9.5 are a lot faster than 5.6.51 for two tests, about as fast for three tests and gets between 10% and 30% less QPS for the other three tests

for writes

MySQL 5.7.44 gets more QPS than 5.6.51 for all tests
MySQL 8.0 to 9.5 get more QPS than 5.6.51 for all tests

Builds, configuration and hardware

I compiled MySQL from source for versions 5.6.51, 5.7.44, 8.0.43, 8.0.44, 8.4.6, 8.4.7, 9.4.0 and 9.5.0.

I used two servers:

small

an ASUS ExpertCenter PN53 with AMD Ryzen 7735HS CPU, 32G of RAM, 8 cores with AMD SMT disabled, Ubuntu 24.04 and an NVMe device with ext4 and discard enabled.

an ax162s from Hetzner with an AMD EPYC 9454P 48-Core Processor with SMT disabled
2 Intel D7-P5520 NVMe storage devices with RAID 1 (3.8T each) using ext4
128G RAM
Ubuntu 22.04 running the non-HWE kernel (5.5.0-118-generic)

The config files are here:

small server: 5.6.51, 5.7.44, 8.0.4x, 8.4.x, 9.x.0
big server: 5.6.51, 5.7.44, 8.0.4x, 8.4.x, 9.x.0

Benchmark

I used sysbench and my usage is explained here. I now run 32 of the 42 microbenchmarks listed in that blog post. Most test only one type of SQL statement. Benchmarks are run with the database cached by InnoDB.

The read-heavy microbenchmarks are run for 600 seconds and the write-heavy for 900 seconds. On the small server the benchmark is run with 1 client and 1 table with 50M rows. On the big server the benchmark is run with 40 clients and 8 tables with 10M rows per table.

The purpose is to search for regressions from new CPU overhead and mutex contention. I use the small server with low concurrency to find regressions from new CPU overheads and then larger servers with high concurrency to find regressions from new CPU overheads and mutex contention.

Results

The microbenchmarks are split into 4 groups -- 1 for point queries, 2 for range queries, 1 for writes. For the range query microbenchmarks, part 1 has queries that don't do aggregation while part 2 has queries that do aggregation.

I provide charts below with relative QPS. The relative QPS is the following:

(QPS for some version) / (QPS for MySQL 5.6.51)

When the relative QPS is > 1 then some version is faster than MySQL 5.6.51. When it is < 1 then there might be a regression. When the relative QPS is 1.2 then some version is about 20% faster than MySQL 5.6.51.

Values from iostat and vmstat divided by QPS are here for the small server and the big server. These can help to explain why something is faster or slower because it shows how much HW is used per request, including CPU overhead per operation (cpu/o) and context switches per operation (cs/o) which are often a proxy for mutex contention.

The spreadsheet and charts are here and in some cases are easier to read than the charts below. Converting the Google Sheets charts to PNG files does the wrong thing for some of the test names listed at the bottom of the charts below.

Results: point queries

This is from the small server.

MySQL 5.7.44 gets about 10% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51
There are few regressions after MySQL 8.0
New CPU overheads explain the regressions. See the vmstat results for the hot-points test.

This is from the large server.

For most point query tests MySQL 5.7 to 9.5 get at least 1.5X more QPS than 5.6.51

MySQL 5.7 to 9.5 use less CPU, see vmstat results for the hot-points test.

For tests that use secondary indexes (*-si) MySQL 5.7 to 9.5 get about 25% less QPS than 5.6.51.

This result is similar to what happens on the small server above.
The regressions are from extra CPU overhead, see vmstat results

MySQL 5.7 does better than 8.0 to 9.5. There are few regressions after MySQL 8.0.

Results: range queries without aggregation

This is from the small server.

MySQL 5.7.44 gets about 15% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51
There are few regressions after MySQL 8.0
New CPU overheads explain the regressions. See the vmstat results for the scan test.

This is from the large server.

MySQL 5.7.44 gets about 10% less QPS than 5.6.51
MySQL 8.0 through 9.5 get about 30% less QPS than 5.6.51
There are few regressions after MySQL 8.0
New CPU overheads explain the regressions. See the vmstat results for the scan test.

Results: range queries with aggregation

This is from the small server.

for the read-only-distinct test, MySQL 5.7 to 9.5 are faster than 5.6.51
for the read-only_range=X tests

with the longest range scan (*_range=10000), MySQL 5.7.44 is faster than 5.6.51 and 8.0 to 9.5 have the same QPS as 5.6.51
with shorter range scans (*_range=100 & *_range=10) MySQL 5.6.51 is faster than 5.7 to 9.5. This implies that the regressions are from code above the storage engine layer.
From vmstat results the perf differences are explained by CPU overheads

for the other tests

MySQL 5.7.44 gets about 15% less QPS than 5.6.51
MySQL 8.0 to 9.5 get about 30% less QPS than 5.6.51
From vmstat results for read-only-count the reason is new CPU overhead

This is from the large server.

for the read-only-distinct test, MySQL 5.7 to 9.5 are faster than 5.6.51
for the read-only_range=X tests

MySQL 5.7.44 is as fast as 5.6.51 for the longest range scan and faster than 5.6.51 for the shorter range scans
MySQL 8.0 to 9.5 are much faster than 5.6.51 for the longest range scan and somewhat faster for the shorter range scans
From vmstat results the perf differences are explained by CPU overheads and possible from changes in mutex contention

for the other tests

MySQL 5.7.44 gets about 20% less QPS than 5.6.51 for read-only-count and about 10% more QPS than 5.6.51 for read-only-simple and read-only-sum
MySQL 8.0 to 9.5 get about 30% less QPS than 5.6.51 for read-only-count and up to 20% less QPS than 5.6.51 for read-only-simple and read-only-sum
From vmstat results for read-only-count the reason is new CPU overhead

Results: writes

This is from the small server.

For most tests

MySQL 5.7.44 gets between 10% and 20% less QPS than 5.6.51
MySQL 8.0 to 9.5 get between 40% to 50% less QPS than 5.6.51
From vmstat results for the insert test, MySQL 5.7 to 9.5 use a lot more CPU

For the update-index test

MySQL 5.7.44 is faster than 5.6.51
MySQL 8.0 to 9.5 get about 10% less QPS than 5.6.51
From vmstat metrics MySQL 5.6.51 has more mutex contention

For the update-inlist test

MySQL 5.7.44 is as fast as 5.6.51
MySQL 8.0 to 9.5 get about 30% less QPS than 5.6.51
From vmstat metrics MySQL 5.6.51 has more mutex contention

This is from the large server and the y-axis truncates the result for the update-index test to improve readability for the other results.

For all tests MySQL 5.7 to 9.5 get more QPS than 5.6.51

From vmstat results for the write-only test MySQL 5.6.51 uses more CPU and has more mutex contention.

For some tests (read-write_range=X) MySQL 8.0 to 9.5 get less QPS than 5.7.44

These are the classic sysbench transaction with different range scan lengths and the performance is dominated by the range query response time, thus 5.7 is fastest.

For most tests MySQL 5.7 to 9.5 have similar perf with two exceptions

For the delete test, MySQL 8.0 to 9.5 are faster than 5.7. From vmstat metrics 5.7 uses more CPU and has more mutex contention than 8.0 to 9.5.
For the update-inlist test, MySQL 8.0 to 9.5 are faster than 5.7. From vmstat metrics 5.7 uses more CPU than 8.0 to 9.5.

This is also from the large server and does not truncate the update-index test result.