Table Maintenance Statements
1165
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
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
) if you want to check tables from time to time. 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 strange 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 the execution plan generated by the query
optimizer.
Some problems reported by
CHECK TABLE
cannot be corrected automatically:
•
Found row where the auto_increment column has the value 0
.
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, simply execute an
UPDATE
statement to set the column to some value
other than 0.
• If
CHECK TABLE
finds a problem for an
InnoDB
table, the server shuts down to prevent error
propagation. Details of the error will be written to the error log.
13.7.2.4.
CHECKSUM TABLE
Syntax
CHECKSUM TABLE
tbl_name
[,
tbl_name
] ... [ QUICK | EXTENDED ]
CHECKSUM TABLE
reports a table checksum.
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.10, “
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, as of MySQL 5.0.3, generates a
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
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.
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...