USE mysql;
SHOW FULL TABLES WHERE table_type = 'base table';
/* returns
…
innodb_index_stats BASE TABLE
innodb_table_stats BASE TABLE
…
*/
SELECT * from innodb_table_stats;
/* returns
Error CODE: 1146
TABLE 'mysql.innodb_table_stats' doesn't exist
*/
SHOW CREATE TABLE innodb_table_stats;
/* returns
Error CODE: 1146
TABLE 'mysql.innodb_table_stats' doesn't exist
*/
Well .. the table exists and also does not exist at the same time. There is a free choice from the shelf! But what is happening? I am not sure yet. It was reported to this bug report by a Linux user, and it is reproducible for me on Windows. Miguel (the MySQL supporter, who is on it) cannot reproduce – not yet at least.
First of all this is just one more example of how a .frm file in MySQL may cause havoc if its content is inconsistent with (existense/accessibility, lack of same or content of) data files (of any storage engine).
I am also not in doubt it is related to 'innodb_file_per_table' set to "1" (MySQL 5.6.7 default). My 5.6.7 server cannot access the .ibd files in the /datadir/mysql folder (existent there due to this configuration parameter setting). I have no problem with other file types in same folder and also no problems with .ibd files anywhere else on the file system. It is also not a file system permissions issue.
I am not aware of any such report with same setting of 'innodb_file_per_table' on earlier MySQL versions – so I think (but cannot be sure) that this is introduced in 5.6.7. Could it be a 'side-effect' of another configuration parameter? Or just a packaging issue? I don't know yet. If anybody has a clue, a comment (here or in the bug report) will be appreciated.