Table Maintenance Statements If a table is corrupted, the problem is most likely in the indexes and not in the data part. All of the preceding check types check the indexes thoroughly and should thus find most errors. To check a table that you assume is okay, use no check options or the  QUICK  option. The latter should be used when you are in a hurry and can take the very small risk that  QUICK  does not find an error in the data file. (In most cases, under normal usage, MySQL should find any error in the data file. If this happens, the table is marked as “corrupted”  and cannot be used until it is repaired.) FAST  and  CHANGED  are mostly intended to be used from a script (for example, to be executed from  cron ) to check tables periodically. In most cases,  FAST  is to be preferred over  CHANGED . (The only case when it is not preferred is when you suspect that you have found a bug in the  MyISAM  code.) EXTENDED  is to be used only after you have run a normal check but still get errors from a table when MySQL tries to update a row or find a row by key. This is very unlikely if a normal check has succeeded. Use of  CHECK TABLE ... EXTENDED  might influence execution plans generated by the query optimizer. Some problems reported by  CHECK TABLE  cannot be corrected automatically: This means that you have a row in the table where the  AUTO_INCREMENT  index column contains the value 0. (It is possible to create a row where the  AUTO_INCREMENT  column is 0 by explicitly setting the column to 0 with an  UPDATE  statement.) This is not an error in itself, but could cause trouble if you decide to dump the table and restore it or do an  ALTER TABLE  on the table. In this case, the  AUTO_INCREMENT  column changes value according to the rules of  AUTO_INCREMENT  columns, which could cause problems such as a duplicate-key error. To get rid of the warning, execute an  UPDATE  statement to set the column to some value other than 0. The following notes apply to  InnoDB  tables: •If  CHECK TABLE  encounters a corrupt page, the server exits to prevent error propagation (Bug #10132). If the corruption occurs in a secondary index but table data is readable, running  CHECK TABLE  can still cause a server exit. •If  CHECK TABLE  encounters a corrupted  DB_TRX_ID  or  DB_ROLL_PTR  field in a clustered index,  CHECK TABLE  can cause  InnoDB  to access an invalid undo log record, resulting in an MVCC-related server exit. •If  CHECK TABLE  encounters errors in  InnoDB  tables or indexes, it reports an error, and usually marks the index and sometimes marks the table as corrupted, preventing further use of the index or table. Such errors include an incorrect number of entries in a secondary index or incorrect links. •If  CHECK TABLE  finds an incorrect number of entries in a secondary index, it reports an error but does not cause a server exit or prevent access to the file. • CHECK TABLE  surveys the index page structure, then surveys each key entry. It does not validate the key pointer to a clustered record or follow the path for  BLOB  pointers. •When an  InnoDB  table is stored in its own  .ibd  file, the first 3 pages of the  .ibd  file contain header information rather than table or index data. The  CHECK TABLE  statement does not detect inconsistencies that affect only the header data. To verify the entire contents of an  InnoDB .ibd  file, use the  innochecksum  command. 2893 CHECK TABLE Usage Notes for InnoDB Tables • Found row where the auto_increment column has the value 0 .