Table Maintenance Statements For  MyISAM  tables created with the  CHECKSUM=1  clause,  CHECKSUM TABLE  or  CHECKSUM TABLE ... QUICK  returns the “live”  table checksum that can be returned very fast. If the table does not meet all these conditions, the  QUICK  method returns  NULL . The  QUICK  method is not supported with  InnoDB  tables. See Section 13.1.20, “CREATE TABLE Statement”  for the syntax of the  CHECKSUM  clause. The checksum value depends on the table row format. If the row format changes, the checksum also changes. For example, the storage format for temporal types such as  TIME ,  DATETIME , and  TIMESTAMP changed in MySQL 5.6 prior to MySQL 5.6.5, so if a 5.5 table is upgraded to MySQL 5.6, the checksum value may change. If the checksums for two tables are different, then it is almost certain that the tables are different in some way. However, because the hashing function used by CHECKSUM TABLE  is not guaranteed to be collision-free, there is a slight chance that two tables which are not identical can produce the same checksum. what you get with the  EXTENDED  clause, with  InnoDB  and all other storage engines other than  MyISAM , and with  MyISAM  tables not created with the  CHECKSUM=1  clause. OPTIMIZE TABLE  reorganizes the physical storage of table data and associated index data, to reduce storage space and improve I/O efficiency when accessing the table. The exact changes made to each table depend on the storage engine used by that table. Use  OPTIMIZE TABLE  in these cases, depending on the type of table: 13.7.3.4 OPTIMIZE TABLE Statement Important OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE  tbl_name  [,  tbl_name ] ... •After doing substantial insert, update, or delete operations on an  InnoDB  table that has its own .ibd file because it was created with the  innodb_file_per_table  option enabled. The table and indexes are reorganized, and disk space can be reclaimed for use by the operating system. •After doing substantial insert, update, or delete operations on columns that are part of a  FULLTEXT  index in an  InnoDB  table. Set the configuration option  innodb_optimize_fulltext_only=1  first. To keep the index maintenance period to a reasonable time, set the  innodb_ft_num_word_optimize  option to specify how many words to update in the search index, and run a sequence of  OPTIMIZE TABLE statements until the search index is fully updated. •After deleting a large part of a  MyISAM  or  ARCHIVE  table, or making many changes to a  MyISAM  or ARCHIVE  table with variable-length rows (tables that have  VARCHAR ,  VARBINARY ,  BLOB , or  TEXT columns). Deleted rows are maintained in a linked list and subsequent  INSERT  operations reuse old row positions. You can use  OPTIMIZE TABLE  to reclaim the unused space and to defragment the data file. After extensive changes to a table, this statement may also improve performance of statements that use the table, sometimes significantly. This statement requires  SELECT  and  INSERT  privileges for the table. OPTIMIZE TABLE  works for  InnoDB ,  MyISAM , and  ARCHIVE  tables.  OPTIMIZE TABLE  is also supported for dynamic columns of in-memory  NDB  tables. It does not work for fixed-width columns of in-memory tables, nor does it work for Disk Data tables. The performance of  OPTIMIZE  on NDB Cluster tables can be tuned using  --ndb-optimization-delay , which controls the length of time to wait between processing batches of rows by  OPTIMIZE TABLE . For more information, see Section 23.1.7.11, “Previous NDB Cluster Issues Resolved in NDB Cluster 8.0” . 2895