Performance Impact of Charset and Collation Settings on MySQL 5.7 vs 8.0

The author conducted a sysbench benchmark to compare the performance impact of different character sets and collations between MySQL 5.7.25 and MySQL 8.0.15.

Test Environment

OS: Ubuntu 18.04 LTS (bionic)

Kernel: 4.15.0-20-generic

CPU: 2 × Intel Xeon Gold 5120 (28 cores, 56 threads)

Memory: 376.6 GB

Two OLTP workloads were used: oltp_read_only and oltp_point_select . The sysbench commands were:

sysbench oltp_read_only --mysql-ssl=off --report-interval=1 --time=300 --threads=$i --tables=10 --table-size=10000000 --mysql-user=root run

sysbench oltp_point_select --mysql-ssl=off --report-interval=1 --time=300 --threads=$i --tables=10 --table-size=10000000 --mysql-user=root run

Results with the latin1 charset showed that MySQL 8.0.15 was about 10% slower on the read‑only workload and 12‑16% slower on the point‑select workload compared to MySQL 5.7.25.

When switching to the utf8mb4 charset, the performance gap changed. MySQL 5.7’s utf8mb4 was 55‑60% slower than its latin1 version, and MySQL 8.0 exhibited a similar slowdown. However, the default collation utf8mb4_general_ci performed worse than utf8mb4_unicode_ci , which gave higher throughput.

Comparing the two MySQL versions using utf8mb4 (default collation) showed that MySQL 8.0 was about 34% faster than MySQL 5.7.

Conclusion

MySQL 5.7 outperforms MySQL 8.0 when using the latin1 charset.

Using utf8mb4, MySQL 8.0 significantly outperforms MySQL 5.7.

MySQL 8.0 defaults to utf8mb4, while MySQL 5.7 defaults to latin1, so charset choice critically affects performance comparisons.