MySQL 5.7 default configuration: what’s new? (and what’s not)

In MySQL by Aurimas Mikalauskas0 Comments

Inspired by Peter Zaitsev’s post for MySQL 5.6, I decided to do a comparison between default configuration of MySQL 5.6 and 5.7. And I gotta tell you, some of the changes I found will have a huge impact on performance so make sure to get yourself familiar with them before you upgrade, even if you’re not otherwise running with a default configuration.


Interestingly, I hit the first roadblock before I could even start. It seems you can no longer extract the same information from the information_schema as in MySQL 5.6, and I had to use performance_schema instead:

With that settled (hence after a mysql_upgrade and a server restart), here’s the result we have:

I’m sure you can spot a few hot items right away, but let’s go over each of them real quick:

It’s no secret MySQL 5.7 is stricter than ever and this is a good example. In the previous versions, MySQL would continue running with binary logging disabled if there was an error writing a binary log which would cause “slight” issues with slaves, but it would keep the master server up. Well, no more. Now if binary logging stops, server stops.
5.7: ROW
Row based replication has definitely been widely tested by now, so not very surprisingly starting with MySQL 5.7, it’s the new norm. RBR solves some performance problems that SBR couldn’t but there’s rarely an upside without the downside and surely RBR has its own (known) issues.
5.6: OFF
5.7: ON
This changes how (and how quickly) the binary logs are iterated when GTID is used. The simple recovery method is faster, although in some special cases it may initialise gtid_executed and gtid_purged incorrectly.
5.6: 10
5.7: 200
eq_range_index_dive_limit was introduced in MySQL 5.6 and in some edge cases, allowed MySQL optimizer to make some, let’s say, suboptimal decisions. This change in MySQL 5.7 significantly increases the chances of correct-ier estimates. See this Mark’s post on it.
5.6: YES
Since symbolic links are only supported by MyISAM, this is now disabled by default. I mean, you’re not really using MyISAM these days, are you? Well then, it should have no impact to you (and I guess don’t have any symlinks anyway).
5.6: OFF
5.7: ON
It’s great to see these are now enabled by default – I’m enabling this feature on pretty much any server I work with anyway. However, I should mention that there was also a new variable introduced – innodb_buffer_pool_dump_pct – which sets the number of pages to dump (25% of all pages by default).
5.6: 8
5.7: 1
Interesting. This should not have been 8 on 5.6, because, according to MySQL manual, it should be 1 if buffer pool is < 1GB. In any case, it looks like it is implemented properly now in MySQL 5.7, where behaviour is supposed to be the same. 1 buffer pool instance if buffer pool < 1GB, 8 buffer pool instances otherwise.
5.6: innodb
5.7: crc32
A great improvement that will save a decent amount of CPU cycles by using native CRC32 instructions. Note that in MySQL 5.7, innodb log checksums are now also calculated using crc32, assuming you leave this at the default setting.
5.6: Antelope
5.7: Barracuda
No big surprises here, glad to see Barracuda format which supports Compressed or Dynamic row formats is finally the default. If you’re still using the old format, don’t worry – it will be supported. This only applies to newly created tablespaces.
5.6: OFF
5.7: ON
I actually had to look this up. Apparently this allows index key prefixes longer than 767 bytes (up to 3072 bytes) for InnoDB tables that use the Dynamic and Compressed row formats. Which kind of makes sense give the move to Barracuda.
5.6: 8M
5.7: 16M
Increases the amount of memory allocated for the InnoDB redo log buffer. On servers with lots of parallel transactions, yeah, it kind of makes sense. For the rest of them, it will not be a huge loss anyway. It’s only 8 megabytes!
5.6: 75
5.7: 75.000000
The real change here is only that it now allows for the fractional part. For an explanation why this is important, see the following blog post.
5.6: 1
5.7: 4
A significant bump up in the number of purge threads. This can be really helpful with write intensive workloads.
5.6: OFF
5.7: ON
What is the innodb_strict_mode you ask? Well, like I said, MySQL 5.7 is stricter than ever and that’s another good example. Now InnoDB throws errors instead of warnings in some cases such as syntax errors in CREATE or ALTER TABLE statements and similar.
5.6: 5.6.28
5.7: 5.7.10
This is another major difference. It looks like in MySQL 5.7, InnoDB major version number was increased by one and minor version was decreased by 18. Interesting.

Okay okay, I’m just messing with you. But it’s good to know the versions we’re comparing, agreed?

5.6: 1
5.7: 2
More verbosity in the error log. With the value of 2, you will also get such information like aborted connections and access denied errors in the error log. Note that in MySQL 5.7, a new (preferred) variable log_error_verbosity was introduced which works very similarly.
5.6: 16 toggles
5.7: 19 toggles
It’s not clear from the original output, but three new optimizer switches were introduced in MySQL 5.7, whereas all of the switches that were available in MySQL 5.6 remained in the same positions. I will discuss the three in the upcoming post where I will talk about new variables introduced in MySQL 5.7.
As you can see, there are a number of changes here. The negative 1 means that the numbers are now autoscaled. I’m yet to figure out how this autoscaling works, but if you would help me with that, I’d be more than happy!
5.6: empty
5.7: /var/lib/mysql-files/
This is a security feature – value is used to limit the effect of data import and export operations (LOAD DATA, SELECT … INTO OUTFILE, LOAD_FILE()) to the given directory (which must exist for it to work). In MySQL 5.6 this was not set by default which means operations were not limited to a particular directory.
5.6: 3600
5.7: 60
This is used on a slave. It will now wait 1 minute instead of 1 hour for more data from the master before giving up, aborting the read and reconnecting. Makes sense to me!
5.6: 0
5.7: 1
A really significant change that may impact performance greatly if, for example, you have innodb_flush_log_at_trx_commit set to 0 or 2. Morgan Tocker from MySQL had a discussion on this topic before the decision was made and I do agree it makes sense to have this safe default. In any case, it’s a really important change and if you’re not sure what sync_binlog is doing, check this out.
5.6: 1
5.7: 16
This variable is also on my shortlist of variables to consider for better performance and I’m really happy to see MySQL has made a default value for it that really makes sense.
5.6: 5.6.28
5.7: 5.7.10
No big surprises here.

What hasn’t (and probably can’t be) changed

I really like the direction MySQL is headed, many of the changes above will make MySQL run better with the default configuration and I’m sure users will appreciate it too. In fact, the number of settings that need to be tweaked for best performance in MySQL 5.7 can now be reduced to:

  • innodb_buffer_pool_size – and you can’t really autoscale this one as it’s not clear if MySQL is running on a dedicated or a shared server, so that’s definitely one of the first things to tune to get the best performance out of your server.
  • innodb_log_file_size – the current default of 48M is much better than 5M that was up until MySQL 5.6, but in many cases you want to increase it even further to improve and stabilise your writes.
  • innodb_flush_method – I’d argue it can now be safely set to O_DIRECT if it’s supported by OS. But until that happens, make sure to set it on Linux.
  • innodb_thread_concurrency – again, hard to autoscale and easy to set to default of 0, offloading scheduling to the OS. Yet in my experience, often controlling the concurrency on InnoDB leads to better results. YMMV.
  • innodb_io_capacity, innodb_io_capacity_max – finally, depending on your disk capabilities, you definitely want to tune this. Unless MySQL knows about your IO subsystem, autoscaling for these variables is not really possible.

And we’re done

Well not really. We’re only midway through it, as we haven’t discussed the new variables that appeared in MySQL 5.7 (and what disappeared – there are some really interesting disappearances too!). And that’s coming shortly. How shortly – depends on you.

Anyway, so what do you think about these changes in the default configuration? Anything bothers you? What would you like to be changed in MySQL 5.8? MySQL Server team is listening to you. Act now!

P.S. If you want to learn more about what all these MySQL variables do, and what configuration you should run for best performance, check out this post: 17 Key MySQL Config File Settings (MySQL 5.7 proof).

Share this Post

About the Author

Aurimas Mikalauskas

Facebook Twitter Google+

Linux hacker since the age of 0xE, deeply passionate about high performance and scalability. Former architect of scalable systems at Percona - largest independent MySQL and MongoDB consultancy company (for 9 years). Audiobook addict, piano & guitar virtuoso, scuba diver, wind surfer and a wannabe glider pilot. Learn more about the author.

Follow Speedemy

I believe that providing the best user experience is the key to business success. Big part of that is making online systems fast, stable and reliable. On, I am sharing best practices and tested methods that I have used for the last 12 years working as an architect of scalable systems and database performance consultant.

If you too are looking to improve the speed and reliability of your system, let's stay in touch:

No spam, ever! Unsubscribe at any time. Powered by ConvertKit