To be honest, the comparison between the two MySQL distributions is not something that excited me a lot. Mainly because from my MySQL memories, I knew that there is not a real difference between the two distributions when talking about the code base.

To my knowledge the differences in the enterprise version are in the additional plugins/components, so unless you explicitly use them, the two solutions’ behavior should be the same or close to it.

So why this article, you may say … 😉

Well, the bear was poked by this (https://blogs.oracle.com/mysql/post/performance-improvements-in-mysql-8035) Oracle blog and by its opening statement: The MySQL team has recently implemented changes that significantly improve the performance of the 8.0.35 version of MySQL Enterprise Edition over the Community Edition.

This, with the results shown, would have been enough for me to trigger the investigation, but there was also how the server was configured that was not making me happy. 

In the mentioned test, we have a total database size of 20 GB with a corresponding InnoDB Buffer Pool of 124GB and other settings diverging from the defaults and best practices as innodb_undo_log_truncate=FALSE. 

Which, in short, means all the work is done in memory and whatever operation on disk is reduced once the data is loaded. The settings were set to satisfy a benchmark, not real production based on fine customization or generic defaults. 

What also moved me was that the article reported between a 17% to 25% increase in performance for the Enterprise version.   

Wow, a 25% increase is a lot. Was it not worth an investigation? Of course, it was, and I did. 

Test environment

I am no Oracle (Neither is Percona), so I based my tests on a poor EC2 instance: m5.xlarge 4 CPUs, 16GB RAM.

I also used the provided volume as the location for the MySQL data directory, while the offline datasets used to reset the data between test runs were on an additional EBS. 

The application node resided in the same network/subnet/zone and was a m5.xlarge as well. 

No proxies or whatever in the middle. 

The configuration for both MySQL Enterprise and Community was mainly based on defaults, except for the following:

In short, disable binlogs, set redolog to something realistic, and, of course, Buffer Pool to a dimension that fits the RAM but not the dataset. All the other parameters are pointers to logs /binaries/libraries. 

The configuration difference was:

The tests

The testing tool was sysbench, and you can read about the test details here.

As also expressed in the plan, we will play with two different datasets, one using more tables and less data per table and the other having more data per table and fewer tables. In both cases the dataset dimension was by far larger than the available memory. 

As mentioned in the above link, we will have three moments for the tests:

  1. Only Reads. This is also a Pre operation that will give us the READ statistics after data load and, as such, fully internally ordered.
  2. Write operations, which may cause (and will) page split/merge and “fragmentation”.
  3. Read as Post write to identify the impact of step two.

To test the servers, I used MySQL 8.2 as the latest Innovation release, counting on the fact that if ANY change had been pushed inside the code, that release should contain it. 

Ok, time to run the tests. Let’s do it!

Tests results

I know I am taking away all the fun and the suspense, but we must start from this.

Sysbench

MySQL 8.2.0 Community vs Enterprise

TPCc like 

  

What? MySQL Community is the best in most of the tests, not Enterprise. How so?  Well, let’s start to dig a bit and understand better what is going on here. 

Sysbench reads first

Here’s how to read the images below:

A green positive value means that MySQL Enterprise was doing better; this counts as +1.

A red negative value means that Community was doing better; this counts as -1.

A blank with 0 is even and doesn’t count. 

You need to read by column, and the result is green only when Enterprise is better than Community in more than 50% of the cases.

Now, as we can see, Enterprise is looking to do better only after the data is loaded and only if the load is spread across more tables. I can already hear the noise… Please have patience and stay with me; everything will be clear soon. 

Also, for writing, Enterprise seems to do better only when the load is spread across multiple tables, pairing community in the other case. 

TPC-c summary

In the case of TPC-c like test, I have run two sets of tests with different isolation methods:

  1. Using Repeatable Read (RR)
  2. Using Read Committed (RC)

TPC-c summary

Here, MySQL Enterprise was never better than Community.

Let us dig a bit!

What was the real delta? What was the difference between the two? To answer this, I will show here the reads and write graphs by tests. 

If you want to see more graphs, please visit here; you will see all the graphs collected, including the statistics collected by Percona Monitoring and Management during the test’s execution. 

While showing you the results of the test, I will refrain from commenting on them. It is my conviction that an image speaks for itself, and in this case, if 100% true, I will make my comments only at the end. 

select_run_inlist

select_run_inlist_hotspot

select_run_point_select

select_run_range_all

select_run_range_distinct

select_run_range_order

select_run_range_simple

select_run_range_sum

select_run_select_scan

Writes

For writes, I am going to show here only the cumulative tests, but you can review the graphs per test in the given GitHub link. 

write_run_write_all_with_trx

write_run_write_all_no_trx

Tpc-c like 

Marco comment 

If you have reached this point, you should have already understood by yourself.

What the graphs show is that the two solutions work almost in parallel, and whenever there is a small advantage for Community or Enterprise, it is just transient by the number of threads, so minimal to be irrelevant.

Conclusions

As suspected, if you test Community and Enterprise using their defaults with a plain configuration/scenario, then between MySQL Community and MySQL Enterprise, there is no difference in performance. 

Possible improvements in features or performance are because of additional components, such as thread-pool.  

So, unless Oracle uses a different Enterprise version from the one available for registered users, I really do not know how we can have a 25% performance increase in Enterprise with plain configuration.  

In any case, the important thing for me was and is that we are not seeing performance (and I hope code) diversion when using the MySQL base code (core) between Community and Enterprise. I hope Oracle keeps doing what it has done until now, enhancing the Enterprise version using the additional components, not the core in close source mode. 

In any case, if you really need some of the Enterprise components, then you should look at Percona Server for MySQL, given we offer most of the Enterprise features in our open and free server solution. 

Percona Distribution for MySQL is a complete, stable, scalable, and secure, open source MySQL solution, delivering enterprise-grade database environments for your most critical business applications. Deploy anywhere and implement easily with one-to-one compatibility with MySQL Community Edition.

 

Try Percona Distribution for MySQL today!

References

https://opensource.com/resources/what-open-source

https://en.wikipedia.org/wiki/Open_source

https://blogs.oracle.com/mysql/post/performance-improvements-in-mysql-8035

https://github.com/Tusamarco/blogs/tree/master/2024_mysql_ent_VS_mysql_community_V820

https://www.mysql.com/products/enterprise/compare/

https://docs.percona.com/percona-server/8.0/feature-comparison.html

 

 

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments