Currently we save explain from the slow log into a JSON blob in the database. This is not searchable. We need to save at least the Key column of explain (multiple entries per explain, one per table) in a way that is indexable. This will allow us to search for queries that use specific indexes.
Complications:
1) Explain output shows aliases rather than table names. We'd need to work backwards with the query to figure out the table name. We need to be able to search by schema.table.index.
2) We need to handle the case where explain output changes for the same query_class. This can happen for multiple reasons, both with user intervention (e.g. adding / changing / removing indexes) and without user intervention (different range in query parameters, data change, index statistics update/change). Reason why this is more important here than in QAN is because index centric analysis is more directly affected by when query_class uses and doesn't use a particular index.
Currently we save explain from the slow log into a JSON blob in the database. This is not searchable. We need to save at least the
Keycolumn of explain (multiple entries per explain, one per table) in a way that is indexable. This will allow us to search for queries that use specific indexes.Complications: 1) Explain output shows aliases rather than table names. We'd need to work backwards with the query to figure out the table name. We need to be able to search by
schema.table.index. 2) We need to handle the case whereexplainoutput changes for the same query_class. This can happen for multiple reasons, both with user intervention (e.g. adding / changing / removing indexes) and without user intervention (different range in query parameters, data change, index statistics update/change). Reason why this is more important here than in QAN is because index centric analysis is more directly affected by when query_class uses and doesn't use a particular index.