explain select * from information_schema.statistics where table_schema=’sakila’\G

I DO get “Scanned 1 database”.

Need to be careful about the right schema column!

SELECTing from STATISTICS (indexes table) — does NOT, sadly:

explain select * from information_schema.statistics where index_schema=’sakila’\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: statistics
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra: Using where; Open_full_table; Scanned all databases

Which is strange, since I would put them on the same level.

With REFERENTIAL_CONSTRAINTS or KEY_COLUMN_USAGE, this does not work, as well. Here, I may reason that FK constraints may refer to tables in two different schemata; so this makes more sense.

mysql> select schema();
+----------+
| schema() |
+----------+
| NULL     |
+----------+
1 row in set (0.00 sec)

mysql> explain select * from information_schema.tables where table_schema = schema();
+----+-------------+--------+------+---------------+------+---------+------+------+-----------------------------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows | Extra                                               |
+----+-------------+--------+------+---------------+------+---------+------+------+-----------------------------------------------------+
|  1 | SIMPLE      | tables | ALL  | NULL          | NULL | NULL    | NULL | NULL | Using where; Skip_open_table; Scanned all databases |
+----+-------------+--------+------+---------------+------+---------+------+------+-----------------------------------------------------+
1 row in set (1.95 sec)

mysql> use test;
Database changed
mysql> select schema();
+----------+
| schema() |
+----------+
| test     |
+----------+
1 row in set (0.00 sec)

mysql> explain select * from information_schema.tables where table_schema = schema();
+----+-------------+--------+------+---------------+--------------+---------+------+------+--------------------------------------------------+
| id | select_type | table  | type | possible_keys | key          | key_len | ref  | rows | Extra                                            |
+----+-------------+--------+------+---------------+--------------+---------+------+------+--------------------------------------------------+
|  1 | SIMPLE      | tables | ALL  | NULL          | TABLE_SCHEMA | NULL    | NULL | NULL | Using where; Open_full_table; Scanned 1 database |
+----+-------------+--------+------+---------------+--------------+---------+------+------+--------------------------------------------------+
1 row in set (0.00 sec)

great post – didn’t know this existed. Unfortunately, it seems my favorite trick to restrict results to the current schema, the SCHEMA() function, doesn’t trigger optimization.

(I mean, SELECT table_name FROM information_schema.TABLES WHERE TABLE_SCHEMA = SCHEMA() will scan all dirs, whereas the equivalent using a string constant instead of SCHEMA() only scans one dir)

Thanks for the information, I never thought to run explain against an information_schema query.

In class I use queries against information_schema to show issues around opening tables, and the table_open_cache and table_definition_cache.

Hitting some columns in the information_schema tables open tables, and/or table_definition.

This option gives me new tools to play with.

Thanks.

Now.. if what happens if we profile a query against information_schema.. Does the server crash.. or do we learn something interesting ? Or both ?

–
Tom Hanlon