Вход на сайт
Просмотр новости

Найдите то, что Вас интересует

Sysbench vs MySQL on a small server: no new regressions, many old ones
Дата публикации: 24-03-2026 21:31:00

This has performance results for InnoDB from MySQL 5.6.51, 5.7.44, 8.0.X, 8.4.8 and 9.7.0 on a small server with sysbench microbenchmarks. The workload here is cached by InnoDB and my focus is on regressions from new CPU overheads. In many cases, MySQL 5.6.51 gets about 1.5X more QPS than modern MySQL (8.0.x thru 9.7). The root cause is new CPU overhead, possibly from code bloat.tl;drThere are too many performance regressions in MySQL 8.0.XThere are few performance regressions in MySQL 8.4 through 9.7.0In many cases MySQL 5.6.51 gets ~1.5X more QPS than 9.7.0 because 9.7.0 uses more CPULarge regressions arrived in MySQL 8.0.30 and 8.0.32, especiall for full-table scansBuilds, configuration and hardwareI compiled MySQL from source for versions 5.6.51, 5.7.44, 8.0.X, 8.4.8 and 9.7.0. For MySQL 8.0.X I used 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36 and 8.0.45.The server is an ASUS ExpertCenter PN53 with AMD Ryzen 7 7735HS, 32G RAM and an m.2 device for the database. More details on it are here. The OS is Ubuntu 24.04 and the database filesystem is ext4 with discard enabled.The my.cnf files are here for 5.6, 5.7, 8.4 and 9.7.The my.cnf files are here fo 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36 and 8.0.45.BenchmarkI used sysbench and my usage is explained here. To save time I only run 32 of the 42 microbenchmarks and most test only 1 type of SQL statement. Benchmarks are run with the database cached by InnoDB.The tests are run using 1 table with 50M rows. The read-heavy microbenchmarks run for 630 seconds and the write-heavy for 930 seconds.ResultsThe 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 tables below with relative QPS. When the relative QPS is > 1 then some version is faster than the base version. When it is < 1 then there might be a regression.  The relative QPS is below where the base version is either MySQL 5.6.51 or 8.0.28:(QPS for some version) / (QPS for base version) Values from iostat and vmstat divided by QPS are here for 5.6.51 as the base version and then here for 8.0.28 as the base version. These can help to explain why something is faster or slower because it shows how much HW is used per request.Results: point queriesSummary:there are large regressions from 5.6.51 to 5.7.44there are larger regressions from 5.7.44 to 8.0.45the regressions from 8.0.45 to 9.7.0 are smallthe regressions in the random-points tests are larger for range=10 than range=1000 (larger when the range is smaller). So the regressions are more likely to be in places other than InnoDB. The problem is new CPU overhead (see cpu/o here) which is 1.55X larger in 9.7.0 vs 5.6.51 for random-points_range=10 but only 1.19X larger in 9.7.0 for random-points_range=1000.Relative to: 5.6.51col-1 : 5.7.44col-2 : 8.0.45col-3 : 8.4.8col-4 : 9.7.0col-1   col-2   col-3   col-40.87    0.65    0.65    0.64    hot-points0.87    0.69    0.67    0.63    point-query0.87    0.72    0.72    0.71    points-covered-pk0.90    0.78    0.78    0.76    points-covered-si0.89    0.73    0.72    0.71    points-notcovered-pk0.89    0.77    0.76    0.75    points-notcovered-si1.00    0.84    0.83    0.83    random-points_range=10000.89    0.72    0.72    0.72    random-points_range=1000.87    0.69    0.68    0.66    random-points_range=10Summary:The large regressions in 8.0.x for point queries (see above) occur prior to 8.0.28Relative to: 8.0.28col-1 : 8.0.30col-2 : 8.0.31col-3 : 8.0.32col-4 : 8.0.33col-5 : 8.0.34col-6 : 8.0.35col-7 : 8.0.36col-8 : 8.0.45col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-80.92    1.14    1.14    1.12    1.17    1.16    1.16    1.16    hot-points0.97    0.97    0.95    0.96    0.95    0.95    0.95    0.95    point-query0.94    1.09    1.09    1.08    1.12    1.12    1.11    1.15    points-covered-pk0.90    1.08    1.07    1.07    1.12    1.13    1.12    1.16    points-covered-si0.91    1.04    1.04    1.03    1.07    1.07    1.06    1.11    points-notcovered-pk0.88    0.96    0.96    0.95    1.00    1.01    1.00    1.06    points-notcovered-si0.79    2.35    2.42    2.37    2.45    2.45    2.47    2.56    random-points_range=10000.94    1.07    1.06    1.06    1.09    1.08    1.10    1.12    random-points_range=1000.93    0.94    0.93    0.93    0.94    0.94    0.93    0.95    random-points_range=10Results: range queries without aggregationSummary:there are large regressions from 5.6.51 to 5.7.44there are larger regressions from 5.7.44 to 8.0.45the regressions from 8.0.45 to 9.7.0 are smallthe problem is new CPU overhead and for the scan test the CPU overhead per query is about 1.5X larger in modern MySQL (8.0 thru 9.7) relative to MySQL 5.6.51 (see cpu/o here)Relative to: 5.6.51col-1 : 5.7.44col-2 : 8.0.45col-3 : 8.4.8col-4 : 9.7.0col-1   col-2   col-3   col-40.83    0.68    0.66    0.65    range-covered-pk0.83    0.70    0.69    0.67    range-covered-si0.84    0.66    0.65    0.64    range-notcovered-pk0.88    0.74    0.73    0.73    range-notcovered-si0.84    0.67    0.66    0.67    scanSummary:There is a large regression in 8.0.30 and a larger one in 8.0.32The scan test is the worst case for the regression.Relative to: 8.0.28col-1 : 8.0.30col-2 : 8.0.31col-3 : 8.0.32col-4 : 8.0.33col-5 : 8.0.34col-6 : 8.0.35col-7 : 8.0.36col-8 : 8.0.45col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-80.95    0.94    0.92    0.92    0.92    0.93    0.93    0.96    range-covered-pk0.96    0.96    0.94    0.93    0.93    0.94    0.93    0.95    range-covered-si0.94    0.94    0.93    0.93    0.94    0.94    0.93    0.93    range-notcovered-pk0.89    0.87    0.87    0.86    0.89    0.91    0.89    0.95    range-notcovered-si0.93    0.92    0.79    0.82    0.83    0.77    0.82    0.80    scanResults: range queries with aggregationSummary:there are large regressions from 5.6.51 to 5.7.44there are larger regressions from 5.7.44 to 8.0.45the regressions from 8.0.45 to 9.7.0 are smallRelative to: 5.6.51col-1 : 5.7.44col-2 : 8.0.45col-3 : 8.4.8col-4 : 9.7.0col-1   col-2   col-3   col-40.86    0.70    0.69    0.68    read-only-count1.42    1.27    1.24    1.23    read-only-distinct0.91    0.75    0.74    0.73    read-only-order1.23    1.01    1.01    1.01    read-only_range=100000.93    0.77    0.76    0.74    read-only_range=1000.86    0.69    0.68    0.66    read-only_range=100.83    0.68    0.68    0.66    read-only-simple0.83    0.67    0.67    0.66    read-only-sumSummary:There are significant regressions in 8.0.30 and 8.0.32Relative to: 8.0.28col-1 : 8.0.30col-2 : 8.0.31col-3 : 8.0.32col-4 : 8.0.33col-5 : 8.0.34col-6 : 8.0.35col-7 : 8.0.36col-8 : 8.0.45col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-80.95    0.94    0.87    0.87    0.88    0.87    0.89    0.91    read-only-count0.97    0.96    0.94    0.95    0.96    0.95    0.95    0.96    read-only-distinct0.97    0.96    0.93    0.95    0.95    0.94    0.95    0.95    read-only-order0.96    0.95    0.93    0.94    0.95    0.95    0.96    0.98    read-only_range=100000.96    0.96    0.94    0.95    0.95    0.94    0.95    0.94    read-only_range=1000.96    0.97    0.95    0.95    0.95    0.94    0.95    0.94    read-only_range=100.94    0.94    0.92    0.93    0.93    0.93    0.94    0.94    read-only-simple0.94    0.94    0.89    0.91    0.92    0.90    0.93    0.91    read-only-sumResults: writesSummary:there are large regressions from 5.6.51 to 5.7.44there are larger regressions from 5.7.44 to 8.0.45the regressions from 8.0.45 to 9.7.0 are smallthe insert test is the worst case and a big part of that is new CPU overhead, see cpu/o here, where it is 2.13X larger in 9.7.0 than 5.6.51. But for update-one the problem is writing more to storage per commit (see wkbpi here) rather than new CPU overhead.Relative to: 5.6.51col-1 : 5.7.44col-2 : 8.0.45col-3 : 8.4.8col-4 : 9.7.0col-1   col-2   col-3   col-40.85    0.60    0.59    0.55    delete0.81    0.55    0.54    0.52    insert0.93    0.75    0.74    0.71    read-write_range=1000.87    0.70    0.68    0.66    read-write_range=101.20    0.88    0.89    0.91    update-index1.04    0.74    0.73    0.71    update-inlist0.87    0.62    0.61    0.57    update-nonindex0.87    0.62    0.60    0.57    update-one0.87    0.63    0.61    0.58    update-zipf0.93    0.69    0.68    0.66    write-onlySummary:There are significant regressions in 8.0.30 and 8.0.32Relative to: 8.0.28col-1 : 8.0.30col-2 : 8.0.31col-3 : 8.0.32col-4 : 8.0.33col-5 : 8.0.34col-6 : 8.0.35col-7 : 8.0.36col-8 : 8.0.45col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-80.96    0.95    0.92    0.92    0.92    0.91    0.91    0.91    delete0.94    0.93    0.91    0.91    0.91    0.90    0.90    0.90    insert0.96    0.96    0.94    0.94    0.94    0.94    0.94    0.93    read-write_range=1000.96    0.96    0.94    0.94    0.94    0.94    0.94    0.93    read-write_range=100.91    0.91    0.84    0.84    0.86    0.85    0.86    0.79    update-index0.94    0.95    0.92    0.91    0.92    0.91    0.91    0.91    update-inlist0.95    0.96    0.92    0.92    0.92    0.91    0.91    0.90    update-nonindex0.96    0.96    0.93    0.92    0.92    0.91    0.92    0.91    update-one0.96    0.96    0.92    0.92    0.92    0.91    0.91    0.90    update-zipf0.94    0.94    0.91    0.91    0.91    0.91    0.91    0.89    write-only
Sysbench vs MySQL on a small server: no new regressions, many old ones appeared first on MariaDB.org


Основное содержимое страницы с новостью.

This has performance results for InnoDB from MySQL 5.6.51, 5.7.44, 8.0.X, 8.4.8 and 9.7.0 on a small server with sysbench microbenchmarks. The workload here is cached by InnoDB and my focus is on regressions from new CPU overheads. 

In many cases, MySQL 5.6.51 gets about 1.5X more QPS than modern MySQL (8.0.x thru 9.7). The root cause is new CPU overhead, possibly from code bloat.

tl;dr

  • There are too many performance regressions in MySQL 8.0.X
  • There are few performance regressions in MySQL 8.4 through 9.7.0
  • In many cases MySQL 5.6.51 gets ~1.5X more QPS than 9.7.0 because 9.7.0 uses more CPU
  • Large regressions arrived in MySQL 8.0.30 and 8.0.32, especiall for full-table scans

Builds, configuration and hardware

I compiled MySQL from source for versions 5.6.51, 5.7.44, 8.0.X, 8.4.8 and 9.7.0. For MySQL 8.0.X I used 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36 and 8.0.45.

The server is an ASUS ExpertCenter PN53 with AMD Ryzen 7 7735HS, 32G RAM and an m.2 device for the database. More details on it are here. The OS is Ubuntu 24.04 and the database filesystem is ext4 with discard enabled.

The my.cnf files are here for 5.6, 5.7, 8.4 and 9.7.

The my.cnf files are here fo 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36 and 8.0.45.

Benchmark

I used sysbench and my usage is explained here. To save time I only run 32 of the 42 microbenchmarks and most test only 1 type of SQL statement. Benchmarks are run with the database cached by InnoDB.

The tests are run using 1 table with 50M rows. The read-heavy microbenchmarks run for 630 seconds and the write-heavy for 930 seconds.

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 tables below with relative QPS. When the relative QPS is > 1 then some version is faster than the base version. When it is < 1 then there might be a regression.  The relative QPS is below where the base version is either MySQL 5.6.51 or 8.0.28:

(QPS for some version) / (QPS for base version) 

Values from iostat and vmstat divided by QPS are here for 5.6.51 as the base version and then here for 8.0.28 as the base version. These can help to explain why something is faster or slower because it shows how much HW is used per request.

Results: point queries

Summary:

  • there are large regressions from 5.6.51 to 5.7.44
  • there are larger regressions from 5.7.44 to 8.0.45
  • the regressions from 8.0.45 to 9.7.0 are small
  • the regressions in the random-points tests are larger for range=10 than range=1000 (larger when the range is smaller). So the regressions are more likely to be in places other than InnoDB. The problem is new CPU overhead (see cpu/o here) which is 1.55X larger in 9.7.0 vs 5.6.51 for random-points_range=10 but only 1.19X larger in 9.7.0 for random-points_range=1000.

Relative to: 5.6.51

col-1 : 5.7.44

col-2 : 8.0.45

col-3 : 8.4.8

col-4 : 9.7.0

col-1   col-2   col-3   col-4

0.87    0.65    0.65    0.64    hot-points

0.87    0.69    0.67    0.63    point-query

0.87    0.72    0.72    0.71    points-covered-pk

0.90    0.78    0.78    0.76    points-covered-si

0.89    0.73    0.72    0.71    points-notcovered-pk

0.89    0.77    0.76    0.75    points-notcovered-si

1.00    0.84    0.83    0.83    random-points_range=1000

0.89    0.72    0.72    0.72    random-points_range=100

0.87    0.69    0.68    0.66    random-points_range=10

Summary:

  • The large regressions in 8.0.x for point queries (see above) occur prior to 8.0.28

Relative to: 8.0.28

col-1 : 8.0.30

col-2 : 8.0.31

col-3 : 8.0.32

col-4 : 8.0.33

col-5 : 8.0.34

col-6 : 8.0.35

col-7 : 8.0.36

col-8 : 8.0.45

col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-8

0.92    1.14    1.14    1.12    1.17    1.16    1.16    1.16    hot-points

0.97    0.97    0.95    0.96    0.95    0.95    0.95    0.95    point-query

0.94    1.09    1.09    1.08    1.12    1.12    1.11    1.15    points-covered-pk

0.90    1.08    1.07    1.07    1.12    1.13    1.12    1.16    points-covered-si

0.91    1.04    1.04    1.03    1.07    1.07    1.06    1.11    points-notcovered-pk

0.88    0.96    0.96    0.95    1.00    1.01    1.00    1.06    points-notcovered-si

0.79    2.35    2.42    2.37    2.45    2.45    2.47    2.56    random-points_range=1000

0.94    1.07    1.06    1.06    1.09    1.08    1.10    1.12    random-points_range=100

0.93    0.94    0.93    0.93    0.94    0.94    0.93    0.95    random-points_range=10

Results: range queries without aggregation

Summary:

  • there are large regressions from 5.6.51 to 5.7.44
  • there are larger regressions from 5.7.44 to 8.0.45
  • the regressions from 8.0.45 to 9.7.0 are small
  • the problem is new CPU overhead and for the scan test the CPU overhead per query is about 1.5X larger in modern MySQL (8.0 thru 9.7) relative to MySQL 5.6.51 (see cpu/o here)

Relative to: 5.6.51

col-1 : 5.7.44

col-2 : 8.0.45

col-3 : 8.4.8

col-4 : 9.7.0

col-1   col-2   col-3   col-4

0.83    0.68    0.66    0.65    range-covered-pk

0.83    0.70    0.69    0.67    range-covered-si

0.84    0.66    0.65    0.64    range-notcovered-pk

0.88    0.74    0.73    0.73    range-notcovered-si

0.84    0.67    0.66    0.67    scan

Summary:

  • There is a large regression in 8.0.30 and a larger one in 8.0.32
  • The scan test is the worst case for the regression.

Relative to: 8.0.28

col-1 : 8.0.30

col-2 : 8.0.31

col-3 : 8.0.32

col-4 : 8.0.33

col-5 : 8.0.34

col-6 : 8.0.35

col-7 : 8.0.36

col-8 : 8.0.45

col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-8

0.95    0.94    0.92    0.92    0.92    0.93    0.93    0.96    range-covered-pk

0.96    0.96    0.94    0.93    0.93    0.94    0.93    0.95    range-covered-si

0.94    0.94    0.93    0.93    0.94    0.94    0.93    0.93    range-notcovered-pk

0.89    0.87    0.87    0.86    0.89    0.91    0.89    0.95    range-notcovered-si

0.93    0.92    0.79    0.82    0.83    0.77    0.82    0.80    scan

Results: range queries with aggregation

Summary:

  • there are large regressions from 5.6.51 to 5.7.44
  • there are larger regressions from 5.7.44 to 8.0.45
  • the regressions from 8.0.45 to 9.7.0 are small

Relative to: 5.6.51

col-1 : 5.7.44

col-2 : 8.0.45

col-3 : 8.4.8

col-4 : 9.7.0

col-1   col-2   col-3   col-4

0.86    0.70    0.69    0.68    read-only-count

1.42    1.27    1.24    1.23    read-only-distinct

0.91    0.75    0.74    0.73    read-only-order

1.23    1.01    1.01    1.01    read-only_range=10000

0.93    0.77    0.76    0.74    read-only_range=100

0.86    0.69    0.68    0.66    read-only_range=10

0.83    0.68    0.68    0.66    read-only-simple

0.83    0.67    0.67    0.66    read-only-sum

Summary:

  • There are significant regressions in 8.0.30 and 8.0.32

Relative to: 8.0.28

col-1 : 8.0.30

col-2 : 8.0.31

col-3 : 8.0.32

col-4 : 8.0.33

col-5 : 8.0.34

col-6 : 8.0.35

col-7 : 8.0.36

col-8 : 8.0.45

col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-8

0.95    0.94    0.87    0.87    0.88    0.87    0.89    0.91    read-only-count

0.97    0.96    0.94    0.95    0.96    0.95    0.95    0.96    read-only-distinct

0.97    0.96    0.93    0.95    0.95    0.94    0.95    0.95    read-only-order

0.96    0.95    0.93    0.94    0.95    0.95    0.96    0.98    read-only_range=10000

0.96    0.96    0.94    0.95    0.95    0.94    0.95    0.94    read-only_range=100

0.96    0.97    0.95    0.95    0.95    0.94    0.95    0.94    read-only_range=10

0.94    0.94    0.92    0.93    0.93    0.93    0.94    0.94    read-only-simple

0.94    0.94    0.89    0.91    0.92    0.90    0.93    0.91    read-only-sum

Results: writes

Summary:

  • there are large regressions from 5.6.51 to 5.7.44
  • there are larger regressions from 5.7.44 to 8.0.45
  • the regressions from 8.0.45 to 9.7.0 are small
  • the insert test is the worst case and a big part of that is new CPU overhead, see cpu/o here, where it is 2.13X larger in 9.7.0 than 5.6.51. But for update-one the problem is writing more to storage per commit (see wkbpi here) rather than new CPU overhead.

Relative to: 5.6.51

col-1 : 5.7.44

col-2 : 8.0.45

col-3 : 8.4.8

col-4 : 9.7.0

col-1   col-2   col-3   col-4

0.85    0.60    0.59    0.55    delete

0.81    0.55    0.54    0.52    insert

0.93    0.75    0.74    0.71    read-write_range=100

0.87    0.70    0.68    0.66    read-write_range=10

1.20    0.88    0.89    0.91    update-index

1.04    0.74    0.73    0.71    update-inlist

0.87    0.62    0.61    0.57    update-nonindex

0.87    0.62    0.60    0.57    update-one

0.87    0.63    0.61    0.58    update-zipf

0.93    0.69    0.68    0.66    write-only

Summary:

  • There are significant regressions in 8.0.30 and 8.0.32

Relative to: 8.0.28

col-1 : 8.0.30

col-2 : 8.0.31

col-3 : 8.0.32

col-4 : 8.0.33

col-5 : 8.0.34

col-6 : 8.0.35

col-7 : 8.0.36

col-8 : 8.0.45

col-1   col-2   col-3   col-4   col-5   col-6   col-7   col-8

0.96    0.95    0.92    0.92    0.92    0.91    0.91    0.91    delete

0.94    0.93    0.91    0.91    0.91    0.90    0.90    0.90    insert

0.96    0.96    0.94    0.94    0.94    0.94    0.94    0.93    read-write_range=100

0.96    0.96    0.94    0.94    0.94    0.94    0.94    0.93    read-write_range=10

0.91    0.91    0.84    0.84    0.86    0.85    0.86    0.79    update-index

0.94    0.95    0.92    0.91    0.92    0.91    0.91    0.91    update-inlist

0.95    0.96    0.92    0.92    0.92    0.91    0.91    0.90    update-nonindex

0.96    0.96    0.93    0.92    0.92    0.91    0.92    0.91    update-one

0.96    0.96    0.92    0.92    0.92    0.91    0.91    0.90    update-zipf

0.94    0.94    0.91    0.91    0.91    0.91    0.91    0.89    write-only

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1Sysbench vs MySQL on a small server: another way to view the regressions09.0109-04-2026
2MySQL 9.7.0 vs sysbench on a small server08.9810-04-2026
3Sysbench vs MariaDB on a small server: using the same charset for all versions08.3206-04-2026
4CPU-bound sysbench on a large server: Postgres, MySQL and MariaDB05.5304-04-2026
5Write-heavy sysbench tests, a large server, modern Postgres and MySQL011.8612-06-2026
6HammerDB tproc-c on a large server, Postgres and MySQL06.515-02-2026
7The Insert Benchmark vs MariaDB 10.2 to 13.0 on a 24-core server012.608-04-2026
8The Insert Benchmark vs MariaDB 10.2 to 13.0 on a 32-core server06.4308-04-2026
9gcc vs clang for sysbench on a small server with Postgres, MySQL and MariaDB07.2431-03-2026
10Selecting a character set for MySQL and MariaDB clients07.4729-03-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 8.8. Источник: mariadb.org.