This would be cool. You can’t get parser to be equivalent to MySQL parser in all cases as there are different versions and even different MySQL Server settings may change things. But it should be good enough for most cases.

You can’t really write full query parser or reliably check which clauses are resolved which way.

I do not really care if it is part of explain or available some other way.

A standalone script (say written in perl or so) would be for me more interresting. This way you could give the script various queries and it will spit out suggestions for indexes needed. Of course in the longer run it would be interresting to have it also available like EXPLAIN EXTENDED or something…

You can run EXPLAIN … \G in which case number of columns is not the problem any more.

Adding two columns will be great, first listing columns which are used from the table and second listing where/on clauses applying to this table and how they are resolved, something like

SELECT count(*) FROM A,B WHERE A.ID=B.ID and A.C>5 and B.D>6;

A:
Used_Columns: ID,C
Checks: C>5(range)

B:
Used_Columns: ID,D
Checks: ID=A.ID(ref), D>6(row)

This would allow to very easy to see which of the checks are not using index which are great candidates for optimization.

I think it would be good, however I’m not sure passing query text is good idea. Might be EXPLAIN can simply feel these tables ready to use or something similar.

The problem with such solution is - it will be unlikely implemented any time soon as it not that trivial.

The other problem it may be a bit complicated to use - some people hate SHOW statements but they are much easier to use compared to information schema

Well, first: it makes as much sense as EXPLAIN. There too, you feed an expression, and you get a resultset back.
second: you cannot join against a SHOW command. Joining is good, you can use it then to parse the code from existing VIEW and PROCEDURE objects via the corresponding tables in he information schema.
third, it makes sense to pass it as a string. That way you can join to VIEW_DEFINITION and ROUTINE_DEFINITION etc columns in the information_schema VIEWS and ROUTINES columns

More purposes: refactoring code (renaming identifiers etc) but then the parse_tree table would also need the exact string position info.

information_schema.parse_tree(
query_text text — query text for which the parse tree is given
, id int unsigned — id for this node
, parent_id int unsigned — id of the parent node (implements adjacency list)
, position int unsigned — position of this node within the sibling nodes
, lft int unsigned — nested set implementation
, rgt int unsigned — nested set implementation
, node_type enum(’identifier’,'constant’,…) — reference to syntax production rule
, node_text text — substring of query_Text that is parsed
)

THe usage would be like this:

select *
from information_schema.parse_tree
where query_text = ’select col1,col2 from aTable where col3 = ”bla”’
;

What would happen is that the parse_tree table would parse the query_text expression, and generate rows for all the nodes in the parse tree.

The nice thing about this table is that you could use for many more things, such as
-discover dependencies between views and tables
-discover dependencies between procedures and other procedures

and…and..

Anyway, what do you think?

Yes I guess it can be used together with some parser to provide some readable output. Being readable is important here as you already can manually dig such info it just takes a lot of effort.

It would be also nice to be able to see which where clauses are resolved doing index lookups and which are post-filtering.