Improve EXPLAIN behaviour

[systay]

Will show the Vitess query plan when prepending a SELECT query with EXPLAIN.
Example output:

mysql> explain select * from tokens;
+-----------------------------------------------------+
| column                                              |
+-----------------------------------------------------+
| {                                                   |
|  "Opcode": "SelectScatter",                         |
|  "Keyspace": {                                      |
|   "Name": "test_keyspace",                          |
|   "Sharded": true                                   |
|  },                                                 |
|  "Query": "select * from tokens",                   |
|  "FieldQuery": "select * from tokens where 1 != 1", |
|  "Table": "tokens"                                  |
| }                                                   |
+-----------------------------------------------------+
10 rows in set (0.00 sec)

[demmer]

The current EXPLAIN support (which passes through the query to one of the tablets) is a useful feature which I don't think we should replace that with the support for showing the query plan from vtgate.

Of course... showing the query plan is also quite useful :)

IMO we should actually integrate the two so that for a simple query, we would merge the vtgate plan info with the mysql level plan. This would be relatively straightforward with EXPLAIN FORMAT=JSON ... since you would just need the one column with two rows -- one for the vtgate query plan and one for the mysql query plan.

But IMO we should also support the traditional explain output. The primitive already has hooks to extract the RouteType and TableName which we could map into the select_type and table columns. With some future enhancements we could maybe even reuse the possible_keys and key columns to show which vindex was used for select queries:

Then the json plan could be stuffed into the Extra column and then merged with the results that we get back from mysql.

mysql> explain select * from messages;
+----+-------------+----------+------------+------+---------------+------+---------+------+-----------+----------+-------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows      | filtered | Extra |
+----+-------------+----------+------------+------+---------------+------+---------+------+-----------+----------+-------+
|  1 | SIMPLE      | messages | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 272256861 |   100.00 | NULL  |
+----+-------------+----------+------------+------+---------------+------+---------+------+-----------+----------+-------+
1 row in set (0.00 sec)

[systay]

Thanks for the feedback, @demmer.

My thinking was that the Vitess query plans forms a tree which at the lowest level most of the time there is one (or many) MySQL instance(s) executing a query. What we could do is to integrate the two trees - any Route in the Vitess plan would be enhanced with a new sub-tree dangling from it - the MySQL plan.

[systay]

Trying again here: #6110