BUMMER

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.

 

Tweet