Table maintenance extensions

Indexes stay up to date with regard to the data within the index data structure.
However,
indexes require periodic maintenance for stability, speed and metadata updates.
Table
maintenance solves the following problems:

Out-of-date table structure

Index and data corruption
Index and data fragmentation
Out-of-date index and data statistics

MySQL has several commands to maintain index and table data:

CHECK TABLE
REPAIR TABLE
CHECKSUM TABLE
ANALYZE TABLE
OPTIMIZE TABLE

Index and data corruption

Corruption can occur to both the data and the indexes belonging to a table, and may
occur for
several reasons. The most common cause of corruption is when data and index files
are changed
at the file system level, or when mysqld crashes, such as when there is not enough
RAM or
the host machine is turned off abruptly without shutting down mysqld properly.
Other, more
infrequent causes of table corruption are hardware problems, such as a
malfunctioning RAID
controller or corrupted RAM, and bugs in the client code, mysqld code, or storage
engine code.
To determine if a table has corruption, use the CHECK TABLE command:
mysql> USE sakila;
Database changed
mysql> CHECK TABLE film\G

CHECK TABLE is only supported by tables using the MyISAM, InnoDB, ARCHIVE, and CSV
storage
engines.

mysql> CHECK TABLE film_text\G

CHECK TABLE takes a comma-separated list of one or more tables and supports the
following
options:

EXTENDED As the name implies, this takes a longer time to run than any other
option.
However, this option will perform a full lookup on all keys and indexes, checking
for
100% data consistency.
MEDIUMThis is the default option used if no option is specified. For every
table, calculate
a checksum for the indexes on each data row, comparing the final result to the
checksum of the index rows. Also verify that deleted links are valid.
 CHANGEDOnly check a table if it was changed since the last time it was checked,
or if
the table was not closed properly. If a table is checked, the checks that are done
are the
same as the MEDIUM option.
FASTOnly check a table if it was not closed properly. If a table is checked, the
checks
that are done are the same as the MEDIUM option.
QUICK Calculate a checksum for the indexes on each data row, comparing the final
result to the checksum of the index rows. Same as MEDIUM, without the verification
for
deleted links.
FOR UPGRADEChecks to see if the table is out of date due to a server upgrade.
Although
this is a quick check, if the table is found to be out of date, a MEDIUM check will
be run
automatically, which can take some time.

Options are specified after the list of tables:

mysql> CHECK TABLE film_text, film FAST;

Common warnings and errors:

Table ./sakila/film_text is marked as crashed and should be repaired

1 client is using or hasnt closed the table properly
Incorrect information in file: ./sakila/film_text.frm
Table ./sakila/film_text is marked as crashed and last (automatic?)
repair failed
Invalid key block position: 284290829344833891 key block size: 1024
file_length: 4453643264
key delete-link-chain corrupted
Table sakila.film_text doesnt exist
Record-count is not ok; is 330426316 Should be: 330426389
Size of datafile is: 0 Should be: 172
Found 1533 deleted space. Should be 0
Found 73 deleted blocks Should be: 0

If CHECK TABLE returns a Msg_type of error, you will need to attempt to fix the
problem.
The first step to try when fixing a corrupt table is REPAIR TABLE. Only the MyISAM,
ARCHIVE,
and CSV storage engines support REPAIR TABLE, and you must have the INSERT and
SELECT
privileges on the tables you want to repair.

mysql> REPAIR TABLE film_text\G

mysql> CHECK TABLE film_text\G

REPAIR TABLE makes all the data and indexes for that table unavailable for the
duration of the repair. Canceling
the repair before it is complete is a bad idea as it will only add to the current
corruption.

REPAIR TABLE optionally takes one of three options after the table name is
specified:
QUICK Only a repair of the index tree is attempted.
EXTENDED Instead of attempting to fix indexes by doing a REPAIR BY SORT on one
entire index at a time, the index is rebuilt one row at a time.
 USE_FRMUses the .frm file to rebuild the index, disregarding the existing .MYI
index
file. This option should be used only as a last resort, as the .MYI file has
important information
that will be lost, such as the AUTO_INCREMENT value. Also, using USE_FRM can
cause fragmentation in the table records.

For tables created using storage engines:

Try rebuilding the table using an ALTER TABLE table_name ENGINE = storage_engine
command, which will force a rebuild of the data and indexes.

Like REPAIR TABLE, rebuilding the data and indexes with this type of ALTER TABLE
command will make all the data and
indexes for the table unusable for the duration of the rebuild. Again, canceling
the ALTER TABLE
before it is complete may add to the current corruption.

Fragmentation

Fragmentation of the data and indexes can occur when the ordering of the index
pages on the
disk are not similar to the index ordering of the records on the pages.
Fragmentation also occurs
when there are a large number of unused pages in the blocks allocated for the
index. Fragmentation
is most often caused when data is deleted, leaving gaps in the index and data files
that may
not be filled even when a new row is inserted.
Resolving fragmentation can be difficult. With some storage engines such as MyISAM
you can
use the OPTIMIZE TABLE command. This will resolve data and index fragmentation
issues. As
with a REPAIR TABLE command, the data and indexes will be unavailable for the
duration of
the OPTIMIZE TABLE.

mysql> OPTIMIZE TABLE film_text;

Tables using the InnoDB storage engine map the OPTIMIZE TABLE command to an ALTER
TABLE command. While this will defragment the row data, it will not always
defragment the
index data.

If the index data is not defragmented by an OPTIMIZE TABLE, only a logical data
export and reimport will resolve index fragmentation.

Reclaiming disk space

When a table that stores its data and indexes directly on the file system is
defragmented, the size
of the files decrease. For example, a fragmented MyISAM table will have smaller
.MYD and .MYI
files after defragmentation. The disk space is automatically reclaimed.
When InnoDB is used and mysqld is set to use innodb_file_per_table, table data and
indexes are stored in a .ibd file in the data directory. All table metadata is
stored together in a
centralized ibdata file. When an InnoDB table is defragmented, its .ibd file will
shrink and
disk space will automatically be reclaimed.
However, by default, mysqld is not set to use innodb_file_per_table, and InnoDB
puts all
of the metadata, data and indexes for all tables into a centralized ibdata file.
When an InnoDB
table is defragmented on this configuration, the ibdata file will not shrink, even
though the
data is successfully defragmented. The good news is that the space is not lost
InnoDB will
add that space to its pool of free space and put new rows in it. The amount of
InnoDB free
space reported in the TABLE_COMMENT field of the INFORMATION_SCHEMA.TABLES system
view
and the Comment field of SHOW TABLE STATUS for an InnoDB table will increase. The
bad news
is that the operating system cannot reclaim that disk space.

Maintaining table statistics

The maintenance of data and indexes should include maintaining the metadata that
the server
stores about table statistics. This is important because the query optimizer uses
this information

in choosing which indexes, if any, to use when executing a query. To recalculate

statistics, use
the ANALYZE TABLE command as shown here:

mysql> ANALYZE TABLE film;

ANALYZE, REPAIR, and OPTIMIZE TABLE statements are written to the binary log by
default, and will be replicated to any slaves. To change this default behavior,
specify
NO_WRITE_TO_BINLOG TABLE between the first word and the word TABLE for example:

REPAIR NO_WRITE_TO_BINLOG TABLE film;

LOCAL is a shorter alias for NO_WRITE_TO_BINLOG and can be used with any of the
three
statements.