Table Maintenance Statements
ANALYZE TABLE Syntax
ANALYZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE
tbl_name [, tbl_name] ...
ANALYZE TABLE analyzes and stores the key distribution for a table. During the analysis, the table is locked with a read lock for InnoDB and MyISAM. This statement works with InnoDB, NDB, and MyISAM tables. For MyISAM tables, this statement is equivalent to using myisamchk --analyze.
For more information on how the analysis works within InnoDB, see Section 14.16.21, “Configuring Optimizer Statistics Parameters”. Also see Section 14.16.22, “Estimating ANALYZE TABLE Complexity for InnoDB Tables” and Section 14.9.7, “Limits on InnoDB Tables”.
MySQL uses the stored key distribution to decide the order in which tables should be joined when you perform a join on something other than a constant. In addition, key distributions can be used when deciding which indexes to use for a specific table within a query.
This statement requires SELECT and INSERT privileges for the table.
ANALYZE TABLE is supported for partitioned tables, and you can use ALTER TABLE ... ANALYZE PARTITION to analyze one or more partitions; for more information, see Section 13.1.7, “ALTER TABLE Syntax”, and Section 19.3.3, “Maintenance of Partitions”.
ANALYZE TABLE returns a result set with the following columns.
| Column |
Value |
| Table |
The table name |
| Op |
Always analyze |
| Msg_type |
status, error, info, note, or warning |
| Msg_text |
An informational message |
You can check the stored key distribution with the SHOW INDEX statement. See Section 13.7.5.23, “SHOW INDEX Syntax”.
If the table has not changed since the last ANALYZE TABLE statement, the table is not analyzed again.
By default, the server writes ANALYZE TABLE statements to the binary log so that they replicate to replication slaves. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.
CHECK TABLE Syntax
CHECK TABLE tbl_name [, tbl_name] ... [option] ...
option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
CHECK TABLE checks a table or tables for errors. CHECK TABLE works for InnoDB, MyISAM, ARCHIVE, and CSV tables. For MyISAM tables, the key statistics are updated as well.
To check a table, you must have some privilege for it.
CHECK TABLE can also check views for problems, such as tables that are referenced in the view definition that no longer exist.
CHECK TABLE is supported for partitioned tables, and you can use ALTER TABLE ... CHECK PARTITION to check one or more partitions; for more information, see Section 13.1.7, “ALTER TABLE Syntax”, and Section 19.3.3, “Maintenance of Partitions”.
Output
CHECK TABLE returns a result set with the following columns.
| Column |
Value |
| Table |
The table name |
| Op |
Always check |
| Msg_type |
status, error, info, note, or warning |
| Msg_text |
An informational message |
Note that the statement might produce many rows of information for each checked table. The last row has a Msg_type value of status and the Msg_text normally should be OK. If you don't get OK, or Table is already up to date you should normally run a repair of the table. See Section 7.6, “MyISAM Table Maintenance and Crash Recovery”. Table is already up to date means that the storage engine for the table indicated that there was no need to check the table.
InnoDB Tables
The following notes apply to InnoDB tables:
- If CHECK TABLE finds a problem for an InnoDB table, the server may shut down to prevent error propagation. Details of the error will be written to the error log.
- If CHECK TABLE encounters corruptions or errors in InnoDB tables or indexes, it reports an error. It does not shut down the server. Starting with MySQL 5.5, CHECK TABLE usually marks the index and sometimes marks the table as corrupted, preventing further use of the index or table.
- If CHECK TABLE finds the wrong number of entries in a secondary index, it will report an error but will not shut down the server 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 in file-per-table mode, the first 3 pages of the .ibd contain header information rather than table or index data. The CHECK TABLE statement does not detect inconsistencies that only affect the header data. To verify the entire contents of an InnoDB .ibd file, use the innochecksum command.
- When running CHECK TABLE on large InnoDB tables, other threads may be blocked during CHECK TABLE execution. To avoid timeouts, the semaphore wait threshold (600 seconds) is extended by 2 hours (7200 seconds) for CHECK TABLE operations. If InnoDB detects semaphore waits of 240 seconds or more it starts printing InnoDB monitor output to the error log. If a lock request extends beyond the semaphore wait threshold, InnoDB will abort the process. To avoid the possibility of a semaphore wait timeout entirely, you can run CHECK TABLE QUICK instead of CHECK TABLE.
CHECKSUM TABLE Syntax
CHECKSUM TABLE tbl_name [, tbl_name] ... [ QUICK | EXTENDED ]
CHECKSUM TABLE reports a table checksum. This statement requires the SELECT privilege for the table.
With QUICK, the live table checksum is reported if it is available, or NULL otherwise. This is very fast. A live checksum is enabled by specifying the CHECKSUM=1 table option when you create the table; currently, this is supported only for MyISAM tables. See Section 13.1.17, “CREATE TABLE Syntax”.
With EXTENDED, the entire table is read row by row and the checksum is calculated. This can be very slow for large tables.
If neither QUICK nor EXTENDED is specified, MySQL returns a live checksum if the table storage engine supports it and scans the table otherwise.
For a nonexistent table, CHECKSUM TABLE returns NULL and generates a warning.
In MySQL 5.5, CHECKSUM TABLE returns 0 for partitioned tables unless you include the EXTENDED option. This issue is resolved in MySQL 5.6. (Bug #11933226, Bug #60681)
The checksum value depends on the table row format. If the row format changes, the checksum also changes. For example, the storage format for VARCHAR changed between MySQL 4.1 and 5.0, so if a 4.1 table is upgraded to MySQL 5.0, the checksum value may change.
OPTIMIZE TABLE Syntax
OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE
tbl_name [, tbl_name] ...
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:
- 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 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.
InnoDB Details
For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE, which rebuilds the table to update index statistics and free unused space in the clustered index. This is displayed in the output of OPTIMIZE TABLE when you run it on an InnoDB table, as shown here:
mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status | OK |
+----------+----------+----------+-------------------------------------------------------------------+
This operation does not use fast index creation. Secondary indexes are not created as efficiently because keys are inserted in the order they appeared in the primary key. See Section 14.14.6, “Limitations of Fast Index Creation”.
InnoDB stores data using a page-allocation method and does not suffer from fragmentation in the same way that legacy storage engines (such as MyISAM) will. When considering whether or not to run optimize, consider the workload of transactions that your server will process:
- Some level of fragmentation is expected. InnoDB only fills pages 93% full, to leave room for updates without having to split pages.
- Delete operations might leave gaps that leave pages less filled than desired, which could make it worthwhile to optimize the table.
- Updates to rows usually rewrite the data within the same page, depending on the data type and row format, when sufficient space is available. See Section 14.10.5, “How Compression Works for InnoDB Tables” and Section 14.12.1, “Overview of InnoDB Row Storage”.
- High-concurrency workloads might leave gaps in indexes over time, as InnoDB retains multiple versions of the same data due through its MVCC mechanism. See Section 14.5.12, “InnoDB Multi-Versioning”.
MyISAM Details
For MyISAM tables, OPTIMIZE TABLE works as follows:
- If the table has deleted or split rows, repair the table.
- If the index pages are not sorted, sort them.
- If the table's statistics are not up to date (and the repair could not be accomplished by sorting the index), update them.
Other Considerations
OPTIMIZE TABLE returns a result set with the following columns.
| Column |
Value |
| Table |
The table name |
| Op |
Always optimize |
| Msg_type |
status, error, info, note, or warning |
| Msg_text |
An informational message |
Note that MySQL locks the table during the time OPTIMIZE TABLE is running.
By default, the server writes OPTIMIZE TABLE statements to the binary log so that they replicate to replication slaves. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.
OPTIMIZE TABLE does not sort R-tree indexes, such as spatial indexes on POINT columns. (Bug #23578)
As of MySQL 5.5.6, OPTIMIZE TABLE table catches and throws any errors that occur while copying table statistics from the old file to the newly created file. For example. if the user ID of the owner of the .frm, .MYD, or .MYI file is different from the user ID of the mysqld process, OPTIMIZE TABLE generates a "cannot change ownership of the file" error unless mysqld is started by the root user.
REPAIR TABLE Syntax
REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE repairs a possibly corrupted table. By default, it has the same effect as myisamchk --recover tbl_name. REPAIR TABLE works for MyISAM, ARCHIVE, and CSV tables. See Section 15.3, “The MyISAM Storage Engine”, and Section 15.6, “The ARCHIVE Storage Engine”, and Section 15.5, “The CSV Storage Engine”
This statement requires SELECT and INSERT privileges for the table.
Normally, you should never have to run REPAIR TABLE. However, if disaster strikes, this statement is very likely to get back all your data from a MyISAM table. If your tables become corrupted often, you should try to find the reason for it, to eliminate the need to use REPAIR TABLE. See Section C.5.4.2, “What to Do If MySQL Keeps Crashing”, and Section 15.3.4, “MyISAM Table Problems”.
REPAIR TABLE returns a result set with the following columns.
| Column |
Value |
| Table |
The table name |
| Op |
Always repair |
| Msg_type |
status, error, info, note, or warning |
| Msg_text |
An informational message |
The REPAIR TABLE statement might produce many rows of information for each repaired table. The last row has a Msg_type value of status and Msg_test normally should be OK. If you do not get OK for a MyISAM table, you should try repairing it with myisamchk --safe-recover. (REPAIR TABLE does not implement all the options of myisamchk.) With myisamchk --safe-recover, you can also use options that REPAIR TABLE does not support, such as --max-record-length.
If you use the QUICK option, REPAIR TABLE tries to repair only the index file, and not the data file. This type of repair is like that done by myisamchk --recover --quick.
If you use the EXTENDED option, MySQL creates the index row by row instead of creating one index at a time with sorting. This type of repair is like that done by myisamchk --safe-recover.
The USE_FRM option is available for use if the .MYI index file is missing or if its header is corrupted. This option tells MySQL not to trust the information in the .MYI file header and to re-create it using information from the .frm file. This kind of repair cannot be done with myisamchk.