I decided to take another look at MySQL 5.6, and realized that I’ve forgotten how many changes this version will have. Each milestone has many improvements, and there have been many milestones, so my memory of the older ones grows hazy. The Fine Manual has the details, but here is my attempt at a quick (and probably incomplete and inaccurate) summary. I’ve emphasized a few changes that will make life significantly better for me.
Replication: RBR can use a more compact format; binary logs are crash-safe; binary logging supports group commit, for much faster performance in the configuration most people use when they care about their data; binlog events have CRC32 checksums to prevent corruption; master- and replica- position are stored in tables as well as files; replication position can now be transactional if that table is InnoDB, so replication is more resilient; mysqlbinlog can connect to a server and stream an exact copy of its binlogs, so you can have realtime binlog backups without needing to use a replica; you can delay replication (no more pt-slave-delay); replication replicas are multi-threaded so that transactions are replayed in per-database threads.
Bug reports already contain references to MySQL version 5.7, so I assume that 5.6 is at least in partial feature freeze. I think the current state of the server might be reasonably close to what will be released as GA, but that is pure speculation.
MySQL 5.6 will make life much easier for me and the users I support. It is very common for my users to write queries with several “derived table” subqueries that are joined together, for example. These currently result in cross joins, and I have to contact users and ask them to rewrite their query into several steps with indexed temporary tables. I am looking forward to the database server taking care of more of these types of issues for me.
At the same time, I share some recent concerns about how easy it is to inspect and understand the changes to the server, especially with regard to bugs and security flaws. Reading source code changesets and bug reports is sometimes the only way to truly understand what the server does, and deep understanding is perhaps the shortest path to trust and confidence.