MySQL released version 8.0.33 on April 18th, featuring some attention-catching features. This blog post is a quick review of the release notes looking for the exciting items, and comments in italics are solely my own.
User-defined collations are now deprecated and will be removed in a future version. This is probably not a show-stopper for most and probably a scary situation for those dependent on them as there may not be an alternative. Hopefully, UTF8MB4 is good enough.
The Performance Shema now has a Server Telemetry Traces service. This interface provides plugins and components a way to retrieve notifications related to SQL statements’ lifetime. We are directed to the Server telemetry traces service section in the MySQL Source Code documentation
The SSL library has been updated to OpenSSL version 1.1.1t.
Inclusive language updates take time
More cleanup in replacing the terms “master,” “slave,” and “MTS” is now replaced in error messages relating to MySQL Replication by “source,” “replica,” and “MTA,” respectively. Many folks incorrectly thought this would be a simple search-and-replace operation, but it takes a while to get this work done. This work started in 2020 and hopefully will be done soon.
Increased mysqlbinlog values
Finally, mysqlbinlog –start-position now accepts values up to 18446744073709551615, unless the –read-from-remote-server or –read-from-remote-source option is also used, in which case the maximum is 4294967295. Thank goodness, how many of you were also stuck when trying to start at 18446744073709551614 and got stuck?
Trying to set a default value for a generated column? Using a generated column with DEFAULT(col_name) to specify the default value for a named column is no longer permitted and now emits an error message.
Bugs closed in MySQL 8.0.33
There are 141 bug fixes included. Thank you, contributors and MySQL Engineering.
Did you notice a difference in query plans between 5.7 and 8.0? Well, here is an interesting bug explanation:
When the MySQL 5.7 Optimizer has two choices for an index to filter rows, one primary and one secondary, it picks a range scan on the secondary index because it uses more key parts. MySQL 8.0 did not use this logic, instead choosing the primary index to filter rows with WHERE clause filtering. Primary key use is not suitable in such cases due to the presence of LIMIT and due to the nature of data distribution. The secondary index was not considered while resolving order by due to constant elimination. This resulted in much different query plans in MySQL 5.7 and MySQL 8.0 for the same query.
We solve this issue in MySQL 8.0 by skipping the constant key parts of the index during order-by evaluation only if the query is constant-optimized, which can be done at this time, but not during LIMIT analysis. (Bug #34291261)
Conclusion
This is an interesting release just because of the sheer volume of over one hundred and forty bug fixes. Is there anything ‘earth shaking’ in ’33? Not for most people. Those with questions about poor query plan generation between 5.7 and 8.0 may want to see if the above fix resolves those issues.
Now instead of upgrading to MySQL Community Server 8.0.33, you might want to look at Percona Server for MySQL. You get enterprise features like data encryption, data masking, RocksDB, and auditing, but you get these enterprise features for free.
Percona Distribution for MySQL is the most complete, stable, scalable, and secure open-source MySQL solution available, delivering enterprise-grade database environments for your most critical business applications… and it’s free to use!
And I forgot to mention
InnoDBnow supports parallel index builds, which improves index build performance. In particular, loading sorted index entries into a B-tree is now multi-threaded. Sorry!