In MySQL 5.7 we are planning to deprecate the syntax:
EXPLAIN PARTITIONS <insert query here> EXPLAIN EXTENDED <insert query here>
.. and enable these two options by default.
The rationale is that:
Simple and consistent is always better.
EXPLAIN FORMAT=JSONalready behaves like these two flags are enabled, and if you have a partitioned table for example, it is unlikely that you would not want the
PARTITIONSoption. Having to remember two more flags makes the product harder to use.
The optimizer team has been busy refactoring and improving code quality. These two flags are supported by many if-statements, increasing complexity by more than we would like.
The intended deprecation plan is to automatically turn both flags on in MySQL 5.7 and issue deprecation warnings when using the older syntax. In MySQL 5.8, the syntax will be removed.
What do I expect will break?
That’s a good question, since
EXPLAIN is really a DBA tool, and is unlikely to affect running applications. I expect it to be:
Automated tools that depend on column order of
EXPLAINnot producing a warning (as of MySQL 5.7).
Automated tools that explicitly use
EXPLAIN EXTENDED(as of MySQL 5.8).
Both I hope should be fairly simple fixes.
How can I make my tools more resilient?
While we’re on the subject of
EXPLAIN and automated tools, it is a good segway to lead into
EXPLAIN FORMAT=JSON, which is very well suited here. I would expect that with
JSON output, applications are more likely to be able to tolerate changes to the information returned and in MySQL 5.7 the JSON is already much more detailed.