Oracle 5.0 Reference Manual page 1185

If a table is corrupted, it is most likely that the problem is 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.
If you just want to check a table that you assume is okay, you should use no check options or the
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
QUICK
any error in the data file. If this happens, the table is marked as "corrupted" and cannot be used until it
is repaired.)
and
FAST CHANGED
cron) if you want to check tables from time to time. In most cases,
CHANGED. (The only case when it is not preferred is when you suspect that you have found a bug in the
code.)
MyISAM
is to be used only after you have run a normal check but still get strange errors from a table
EXTENDED
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
optimizer.
Some problems reported by
•
Found row where the auto_increment column has the value
This means that you have a row in the table where the
value 0. (It is possible to create a row where the
the column to 0 with an
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
according to the rules of
duplicate-key error.
To get rid of the warning, simply execute an
other than 0.
• If
CHECK TABLE
propagation. Details of the error will be written to the error log.
13.7.2.4.
CHECKSUM TABLE
CHECKSUM TABLE
CHECKSUM TABLE
With QUICK, the live table checksum is reported if it is available, or
A live checksum is enabled by specifying the
currently, this is supported only for
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
supports it and scans the table otherwise.
For a nonexistent table,
warning.
The checksum value depends on the table row format. If the row format changes, the checksum also
changes. For example, the storage format for
4.1 table is upgraded to MySQL 5.0, the checksum value may change.
Table Maintenance Statements
are mostly intended to be used from a script (for example, to be executed from
CHECK TABLE
statement.)
UPDATE
on the table. In this case, the
AUTO_INCREMENT
finds a problem for an
Syntax
tbl_name [, tbl_name] ... [ QUICK | EXTENDED ]
reports a table checksum.
MyISAM
nor is specified, MySQL returns a live checksum if the table storage engine
EXTENDED
CHECKSUM TABLE
might influence the execution plan generated by the query
cannot be corrected automatically:
AUTO_INCREMENT
AUTO_INCREMENT
AUTO_INCREMENT
columns, which could cause problems such as a
statement to set the column to some value
UPDATE
table, the server shuts down to prevent error
InnoDB
table option when you create the table;
CHECKSUM=1
tables. See Section 13.1.10,
returns and, as of MySQL 5.0.3, generates a
NULL
changed between MySQL 4.1 and 5.0, so if a
VARCHAR
1165
is to be preferred over
FAST
0.
index column contains the
column is 0 by explicitly setting
column changes value
otherwise. This is very fast.
NULL
"CREATE TABLE Syntax".