Question posted in 
I’ve been testing the performance between 5.7 and 8.0.
We figured out that our application is around 30% slower with 8.0, so I tried to narrow down the issue.
I’ve started running simple sysbench tests and they showed the same perf hit.
Then I found this nice article.
I tried to replicate the setup (4 cores, NVMe backend, only VM on the host, etc) the best I can.
I used two separate VMs based on CentOS 7 with community editions.
However, after tests I got the same ~30% perf hit with the same scripts found in the blog post.
Then I tried to add the my.cnf options mentioned in the blog, nothing. Apart from these options, my.cnf was left as default (except innodb_buffer_pool, which was set to 8G from the start and binlogs were disabled on both).
As a last resort I just tried a simple sysbench run (removed all the extra options, ran it for 10 minutes), same thing.
I even tried to force M8 to use latin1 instead of utf8 (while creating the DB), which yielded these (best) results:
Results
Everything points to M8 having way less performance as M5.7, which contradicts ALL google listing.
Does anyone have any idea where the perf hit comes from?
Thanks in advance!
2
Answers
8.0 implements ROLLBACK for DDL statements such as CREATE/DROP/ALTER TABLE/DATABASE/COLUMN. This makes them slower.
For most applications, this is not a performance problem because DDL is only a rare event. Are you doing a lot of DDL statements?
From several9s, that shows tons of improvements that are present in MySQL 8.0. The benchmark results reveals that there has been an impressive improvement, not only on managing read workloads, but also on a high read/write workload comparing to MySQL 5.7.
Here are the benchmark results:
Overall, MySQL 8.0 has dominated MySQL 5.7 efficiently. Especially if you have a high number of threads, I believe you must use MySQL 8.0.