This post discusses the next MySQL development milestone: MySQL 8.0.1.
From the outset, MySQL 8.0 has received plenty of attention. Both this blog (see the MySQL 8.0 search) and other sites around the Internet have covered it. Early reviews seem positive (including my own MySQL 8.0 early bugs review). There is plenty of excitement about the new features.
As for early feedback on MySQL 8.0, Peter Zaitsev (Percona CEO) listed a set of recommendations for benchmarking MySQL 8.0. I hope these get reviewed and implemented.
MySQL achieved the current development milestone (available for download on dev.mysql.com) on September 12, 2016. Its release immediately came with a detailed review by Geir Hoydalsvik from MySQL. If you haven’t had the opportunity to do so yet, you can also review the MySQL 8.0 release notes.
It now looks like we’re nearing 8.0.1, the next development milestone. I don’t have insider information, but it’s quite clear when navigating mysql.com that:
- The release notes for 8.0.1, even if perhaps not fully finalized yet, are already available at:
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html - Hidden within the new MySQL 8.0.1 features list you’ll find things like InnoDB Redo Log Encryption, libmysqld removal, a YaSSL upgrade, and more
- https://dev.mysql.com/doc/relnotes/mysql/8.0/en/ now includes 8.0.1
Regarding timing, it’s interesting to note that the “What Is New in MySQL 8.0” page was updated on the 6th of January.
It looks like the release might come soon. So, restrain your excitement for a few days (or weeks?) more. Maybe you’ll be able to checkout the all new MySQL 8.0.1!
PS: If MySQL quality interests you, have a look at this recent – and very interesting – change made to the MTR (MySQL Test Run, the MySQL test suite) program. I believe it improves quality for everyone who runs MySQL (including its forks). The tests (which are run worldwide, often for each code change made) will now test the product with its own defaults.
8.0: “Previously, indexes could be scanned in reverse order but at a performance penalty.” I assume the penalty instead of creating two index (one asc and one desc) when I run SELECT to datetimes in both direction (datetime NOW()). I cannot find the relevance of DESC index, when prior 8.0.1 I can use on index on both scan direction.
How much is the advantage of it is percent?