O'Reilly logo

MySQL Reference Manual by Kaj Arno, David Axmark, Michael Widenius

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Disaster Prevention and Recovery

Database Backups

Because MySQL tables are stored as files, it is easy to do a backup. To get a consistent backup, do a LOCK TABLES on the relevant tables followed by FLUSH TABLES for the tables. See Section 6.7.2, and Section 4.5.3. You only need a read lock; this allows other threads to continue to query the tables while you are making a copy of the files in the database directory. The FLUSH TABLE is needed to ensure that all the active index pages are written to disk before you start the backup.

If you want to make a SQL-level backup of a table, you can use SELECT INTO OUTFILE or BACKUP TABLE. See Section 6.4.1, and Section 4.4.2.

Another way to back up a database is to use the mysqldump program or the mysqlhotcopy script, and Section 4.8.5. See Section 4.8.6.

  1. Do a full backup of your databases:

    shell> mysqldump --tab=/path/to/some/dir --opt --full
    
    or
    
    shell> mysqlhotcopy database /path/to/some/dir

    You can also simply copy all table files (*.frm, *.MYD, and *.MYI files) as long as the server isn’t updating anything. The script mysqlhotcopy does use this method.

  2. Stop mysqld if it’s running, then start it with the --log-update[=file_name] option. See Section 4.9.3. The update log file(s) provide you with the information you need to replicate changes to the database that are made subsequent to the point at which you executed mysqldump.

If you have to restore something, try to recover your tables using REPAIR TABLE or myisamchk -r first. That should work in 99.9% of all cases. If myisamchk fails, try the following procedure (this will only work if you have started MySQL with --log-update; see Section 4.9.3):

  1. Restore the original mysqldump backup.

  2. Execute the following command to re-run the updates in the binary log:

    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    If you are using the update log you can use:

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

ls is used to get all the update log files in the right order.

You can also do selective backups with SELECT * INTO OUTFILE 'file_name' FROM tbl_name and restore with LOAD DATA INFILE 'file_name' REPLACE ... To avoid duplicate records, you need a PRIMARY KEY or a UNIQUE key in the table. The REPLACE keyword causes old records to be replaced with new ones when a new record duplicates an old record on a unique key value.

If you get performance problems in making backups on your system, you can solve this by setting up replication and do the backups on the slave instead of on the master. See Section 4.10.1.

If you are using a Veritas filesystem, you can:

  1. From a client (or Perl), execute: FLUSH TABLES WITH READ LOCK.

  2. From another shell, execute: mount vxfs snapshot.

  3. From the first client, execute: UNLOCK TABLES.

  4. Copy files from snapshot.

  5. Unmount snapshot.

BACKUP TABLE Syntax

BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'

Copy to the backup directory the minimum number of table files needed to restore the table. This currently only works for MyISAM tables. For MyISAM tables, copy .frm (definition) and .MYD (data) files. The index file can be rebuilt from those two.

Before using this command, please see Section 4.4.1.

During the backup, read locks will be held for each table, one at time, as they are being backed up. If you want to back up several tables as a snapshot, you must first issue LOCK TABLES obtaining a read lock for each table in the group.

The command returns a table with the following columns:

Column

Value

Table

Table name

Op

Always “backup”

Msg_type

One of status, error, info, or warning.

Msg_text

The message

Note that BACKUP TABLE is only available in MySQL Version 3.23.25 and later.

RESTORE TABLE Syntax

RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'

Restores the table(s) from the backup that was made with BACKUP TABLE. Existing tables will not be overwritten—if you try to restore over an existing table, you will get an error. Restore will take longer than BACKUP due to the need to rebuild the index. The more keys you have, the longer it is going to take. Just as with BACKUP TABLE, RESTORE TABLE currently only works with MyISAM tables.

The command returns a table with the following columns:

Column

Value

Table

Table name

Op

Always “restore”

Msg_type

One of status, error, info, or warning

Msg_text

The message

CHECK TABLE Syntax

CHECK TABLE tbl_name[,tbl_name...] [option [option...]]

option = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE only works on MyISAM and InnoDB tables. On MyISAM tables it’s the same thing as running myisamchk -m table_name on the table.

If you don’t specify any option, MEDIUM is used.

CHECK TABLE checks the table(s) for errors. For MyISAM tables the key statistics are updated. The command returns a table with the following columns:

Column

Value

Table

Table name

Op

Always “check”

Msg_type

One of status, error, info, or warning

Msg_text

The message

Note that you can get many rows of information for each checked table. The last row will be of Msg_type status and should normally be OK. If you don’t get OK, or if you get Not checked, you should normally run a repair of the table. See Section 4.4.6. Not checked means that the table TYPE told MySQL that there wasn’t any need to check the table.

The different check types stand for the following:

Type

Meaning

QUICK

Don’t scan the rows to check for wrong links.

FAST

Only check tables which haven’t been closed properly.

CHANGED

Only check tables which have been changed since the last check or haven’t been closed properly.

MEDIUM

Scan rows to verify that deleted links are okay. This also calculates a key checksum for the rows and verifies this with a calculated checksum for the keys.

EXTENDED

Do a full key lookup for all keys for each row. This ensures that the table is 100% consistent, but will take a long time!

For dynamically sized MyISAM tables a started check will always do a MEDIUM check. For statically size rows we skip the row scan for QUICK and FAST as the rows are very seldom corrupted.

You can combine check options as in:

CHECK TABLE test_table FAST QUICK;

which would simply do a quick check on the table to see whether it was closed properly.

Note: In some case CHECK TABLE will change the table! This happens if the table is marked as ‘corrupted’ or ‘not closed properly’ but CHECK TABLE didn’t find any problems in the table. In this case CHECK TABLE will mark the table as okay.

If a table is corrupted, it’s most likely that the problem is in the indexes and not in the data part. All of the previous 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 didn’t find an error in the data file. (In most cases MySQL should find, under normal usage, any error in the data file. If this happens then the table will be marked as ‘corrupted', in which case the table can’t be used until it’s 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 your table from time to time. In most cases FAST is preferred over CHANGED. (The only case when it isn’t is when you have found a bug in the MyISAM code.)

EXTENDED is only to be used 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!).

Some things reported by check table can’t be corrected automatically:

  • Found row where the auto_increment column has the value 0.

    This means that you have in the table a row where the AUTO_INCREMENT index column contains the value 0. (It’s possible to create a row where the AUTO_INCREMENT column is 0 by explicitly setting the column to 0 with an UPDATE statement.)

    This isn’t 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 will change value, according to the rules of AUTO_INCREMENT columns, which could cause problems like a duplicate key error.

    To get rid of the warning, just execute an UPDATE statement to set the column to some value other than 0.

REPAIR TABLE Syntax

REPAIR TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE only works on MyISAM tables and is the same as running myisamchk -r table_name on the table.

Normally you should never have to run this command, but if disaster strikes you are very likely to get back all your data from a MyISAM table with REPAIR TABLE. If your tables get corrupted a lot you should try to find the reason for this! See Section A.4.1, and Section 7.1.3.

REPAIR TABLE repairs a possible corrupted table. The command returns a table with the following columns:

Column

Value

Table

Table name

Op

Always “repair”

Msg_type

One of status, error, info, or warning

Msg_text

The message

Note that you can get many rows of information for each repaired table. The last row will be of Msg_type status and should normally be OK. If you don’t get OK, you should try repairing the table with myisamchk -o, as REPAIR TABLE does not yet implement all the options of myisamchk. In the near future, we will make it more flexible.

If QUICK is given, MySQL will try to do a REPAIR of only the index tree.

If you use EXTENDED, MySQL will create the index row by row instead of creating one index at a time with sorting; this may be better than sorting on fixed-length keys if you have long char( ) keys that compress very well.

As of MySQL 4.0.2 there is a USE_FRM mode for REPAIR. Use it if the .MYI file is missing or if its header is corrupted. In this mode MySQL will re-create the table, using information from the .frm file. This kind of repair cannot be done with myisamchk.

Using myisamchk for Table Maintenance and Crash Recovery

Starting with MySQL Version 3.23.13, you can check MyISAM tables with the CHECK TABLE command. See Section 4.4.4. You can repair tables with the REPAIR TABLE command. See Section 4.4.5.

To check/repair MyISAM tables (.MYI and .MYD) you should use the myisamchk utility. To check/repair ISAM tables (.ISM and .ISD) you should use the isamchk utility. See Chapter 7.

In the following text we will talk about myisamchk, but everything also applies to the old isamchk.

You can use the myisamchk utility to get information about your database tables, check and repair them, or optimise them. The following sections describe how to invoke myisamchk (including a description of its options), how to set up a table maintenance schedule, and how to use myisamchk to perform its various functions.

You can, in most cases, also use the command OPTIMIZE TABLES to optimise and repair tables, but this is not as fast or reliable (in case of real fatal errors) as myisamchk. On the other hand, OPTIMIZE TABLE is easier to use and you don’t have to worry about flushing tables. See Section 4.5.1.

Even though the repair in myisamchk is quite secure, it’s always a good idea to make a backup before doing a repair (or anything that could make a lot of changes to a table).

myisamchk invocation syntax

myisamchk is invoked like this:

shell> myisamchk [options] tbl_name

The options specify what you want myisamchk to do. They are described next. (You can also get a list of options by invoking myisamchk --help.) With no options, myisamchk simply checks your table. To get more information or to tell myisamchk to take corrective action, specify options as described here and in the following sections.

tbl_name is the database table you want to check/repair. If you run myisamchk somewhere other than in the database directory, you must specify the path to the file because myisamchk has no idea where your database is located. Actually, myisamchk doesn’t care whether the files you are working on are located in a database directory; you can copy the files that correspond to a database table into another location and perform recovery operations on them there.

You can name several tables on the myisamchk command-line if you wish. You can also specify a name as an index filename (with the .MYI suffix), which allows you to specify all tables in a directory by using the pattern *.MYI. For example, if you are in a database directory, you can check all the tables in the directory like this:

shell> myisamchk *.MYI

If you are not in the database directory, you can check all the tables there by specifying the path to the directory:

shell> myisamchk /path/to/database_dir/*.MYI

You can even check all tables in all databases by specifying a wildcard with the path to the MySQL data directory:

shell> myisamchk /path/to/datadir/*/*.MYI

The recommended way to quickly check all tables is:

myisamchk --silent --fast /path/to/datadir/*/*.MYI
isamchk --silent /path/to/datadir/*/*.ISM

If you want to check all tables and repair all tables that are corrupted, you can use the following line:

myisamchk --silent --force --fast --update-state -O key_buffer=64M \
          -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
          /path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
        -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM

This assumes that you have more than 64M of free space.

Note that if you get an error like:

myisamchk: warning: 1 clients is using or hasn't closed the table properly

this means that you are trying to check a table that has been updated by the another program (like the mysqld server) that hasn’t yet closed the file or that has died without closing the file properly.

If mysqld is running, you must force a sync/close of all tables with FLUSH TABLES and ensure that no one is using the tables while you are running myisamchk. In MySQL Version 3.23 the easiest way to avoid this problem is to use CHECK TABLE instead of myisamchk to check tables.

General options for myisamchk

myisamchk supports the following options.

-# or --debug=debug_options

Output debug log. The debug_options string often is 'd:t:o,filename'.

-? or --help

Display a help message and exit.

-O var=option, --set-variable var=option

Set the value of a variable. The possible variables and their default values for myisamchk can be examined with myisamchk --help:

Variable

Value

key_buffer_size

523264

read_buffer_size

262136

write_buffer_size

262136

sort_buffer_size

2097144

sort_key_blocks

16

decode_bits

9

sort_buffer_size is used when the keys are repaired by sorting keys, which is the normal case when you use --recover.

key_buffer_size is used when you are checking the table with --extended-check or when the keys are repaired by inserting keys row by row into the table (like when doing normal inserts). Repairing through the key buffer is used in the following cases:

  • If you use --safe-recover.

  • If the temporary files needed to sort the keys would be more than twice as big as when creating the key file directly. This is often the case when you have big CHAR, VARCHAR, or TEXT keys as the sort needs to store the keys in their entirety during sorting. If you have lots of temporary space and you can force myisamchk to repair by sorting you can use the --sort-recover option.

Reparing through the key buffer takes much less disk space than using sorting, but is also much slower.

If you want a faster repair, set the preceding variables to about 1/4 of your available memory. You can set both variables to big values, as only one of the preceding buffers will be used at a time.

-s or --silent

Silent mode. Write output only when errors occur. You can use -s twice (-ss) to make myisamchk very silent.

-v or --verbose

Verbose mode. Print more information. This can be used with -d and -e. Use -v multiple times (-vv, -vvv) for more verbosity!

-V or --version

Print the myisamchk version and exit.

-w or, --wait

Instead of giving an error if the table is locked, wait until the table is unlocked before continuing. Note that if you are running mysqld on the table with --skip-locking, the table can only be locked by another myisamchk command.

Check options for myisamchk

-c or --check

Check table for errors. This is the default operation if you are not giving myisamchk any options that override this.

-e or --extend-check

Check the table very thoroughly (which is quite slow if you have many indexes). This option should only be used in extreme cases. Normally, myisamchk or myisamchk --medium-check should, in most cases, be able to find out if there are any errors in the table.

If you are using --extended-check and have much memory, you should increase the value of key_buffer_size a lot!

-F or --fast

Check only tables that haven’t been closed properly.

-C or --check-only-changed

Check only tables that have changed since the last check.

-f or --force

Restart myisamchk with -r (repair) on the table, if myisamchk finds any errors in the table.

-i or --information

Print informational statistics about the table that is checked.

-m or --medium-check

Faster than extended-check, but only finds 99.99% of all errors. Should, however, be good enough for most cases.

-U or --update-state

Store in the .MYI file when the table was checked and if the table crashed. This should be used to get the full benefit of the --check-only-changed option, but you shouldn’t use this option if the mysqld server is using the table and you are running mysqld with --skip-locking.

-T or --read-only

Don’t mark table as checked. This is useful if you use myisamchk to check a table that is in use by some other application that doesn’t use locking (like mysqld --skip-locking).

Repair options for myisamchk

The following options are used if you start myisamchk with -r or -o:

-D # or --data-file-length=#

Max length of data file (when re-creating data file when it’s “full').

-e or --extend-check

Try to recover every possible row from the data file. Normally this will also find a lot of garbage rows. Don’t use this option if you are not totally desperate.

-f or --force

Overwrite old temporary files (table_name.TMD) instead of aborting.

-k # or keys-used=#

If you are using ISAM, this option tells the ISAM table handler to update only the first # indexes. If you are using MyISAM, this option tells which keys to use, where each binary bit stands for one key (first key is bit 0). This can be used to get faster inserts! Deactivated indexes can be reactivated by using myisamchk -r. keys.

-l or --no-symlinks

Do not follow symbolic links. Normally myisamchk repairs the table a symlink points at. This option doesn’t exist in MySQL 4.0, as MySQL 4.0 will not remove symlinks during repair.

-r or --recover

Can fix almost anything except unique keys that aren’t unique (which is an extremely unlikely error with ISAM/MyISAM tables). If you want to recover a table, this is the option to try first. Only if myisamchk reports that the table can’t be recovered by -r, you should then try -o. (Note that in the unlikely case that -r fails, the data file is still intact.) If you have lots of memory, you should increase the size of sort_buffer_size!

-o or --safe-recover

Uses an old recovery method (reads through all rows in order and updates all index trees based on the found rows); this is an order of magnitude slower than -r, but can handle a couple of very unlikely cases that -r cannot handle. This recovery method also uses much less disk space than -r. Normally one should always first repair with -r, and only if this fails use -o.

If you have lots of memory, you should increase the size of key_buffer_size!

-n or --sort-recover

Force myisamchk to use sorting to resolve the keys even if the temporary files should be very big.

--character-sets-dir=...

Directory where character sets are stored.

--set-character-set=name

Change the character set used by the index.

-t or --tmpdir=path

Path for storing temporary files. If this is not set, myisamchk will use the environment variable TMPDIR for this.

-q or --quick

Faster repair by not modifying the data file. One can give a second -q to force myisamchk to modify the original data file in case of duplicate keys.

-u or --unpack

Unpack file packed with myisampack.

Other options for myisamchk

Other actions that myisamchk can do, besides repair and check tables:

-a or --analyze

Analyse the distribution of keys. This improves join performance by enabling the join optimiser to better choose in which order it should join the tables and which keys it should use: myisamchk --describe --verbose table_name' or using SHOW KEYS in MySQL.

-d or --description

Prints some information about the table.

-A or --set-auto-increment[=value]

Force AUTO_INCREMENT to start at this or a higher value. If no value is given, this sets the next AUTO_INCREMENT value to the highest-used value for the auto key + 1.

-S or --sort-index

Sort the index tree blocks in high-low order. This will optimise seeks and will make table scanning by key faster.

-R or --sort-records=#

Sorts records according to an index. This makes your data much more localised and may speed up ranged SELECT and ORDER BY operations on this index. (It may be very slow to do a sort the first time!) To find out a table’s index numbers, use SHOW INDEX, which shows a table’s indexes in the same order that myisamchk sees them. Indexes are numbered beginning with 1.

myisamchk memory usage

Memory allocation is important when you run myisamchk. myisamchk uses no more memory than you specify with the -O options. If you are going to use myisamchk on very large files, you should first decide how much memory you want it to use. The default is to use only about 3M to fix things. By using larger values, you can get myisamchk to operate faster. For example, if you have more than 32M RAM, you could use options such as these (in addition to any other options you might specify):

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

Using -O sort=16M should probably be enough for most cases.

Be aware that myisamchk uses temporary files in TMPDIR. If TMPDIR points to a memory filesystem, you may easily get “out of memory” errors. If this happens, set TMPDIR to point at some directory with more space and restart myisamchk.

When repairing, myisamchk will also need a lot of disk space:

  • Double the size of the record file (the original one and a copy). This space is not needed if one does a repair with --quick, as in this case only the index file will be re-created. This space is needed on the same disk as the original record file!

  • Space for the new index file that replaces the old one. The old index file is truncated at start, so one usually ignores this space. This space is needed on the same disk as the original index file!

  • When using --recover or --sort-recover (but not when using --safe-recover), you will need space for a sort buffer for: (largest_key + row_pointer_length)*number_of_rows * 2. You can check the length of the keys and the row_pointer_length with myisamchk -dv table. This space is allocated on the temporary disk (specified by TMPDIR or --tmpdir=#).

If you have a problem with disk space during repair, you can try to use --safe-recover instead of --recover.

Using myisamchk for crash recovery

If you run mysqld with --skip-locking (which is the default on some systems, like Linux), you can’t reliably use myisamchk to check a table when mysqld is using the same table. If you can be sure that no one is accessing the tables through mysqld while you run myisamchk, you only have to do mysqladmin flush-tables before you start checking the tables. If you can’t guarantee this, you must take down mysqld while you check the tables. If you run myisamchk while mysqld is updating the tables, you may get a warning that a table is corrupt even if it isn’t.

If you are not using --skip-locking, you can use myisamchk to check tables at any time. While you do this, all clients that try to update the table will wait until myisamchk is ready before continuing.

If you use myisamchk to repair or optimise tables, you must always ensure that the mysqld server is not using the table (this also applies if you are using --skip-locking). If you don’t take down mysqld you should at least do a mysqladmin flush-tables before you run myisamchk. Your tables may be corrupted if the server and myisamchk access the tables simultaneously.

This chapter describes how to check for and deal with data corruption in MySQL databases. If your tables get corrupted frequently you should try to find the reason for this! See Section A.4.1.

The MyISAM table section contains reasons why a table could be corrupted. See Section 7.1.3.

When performing crash recovery, it is important to understand that each table tbl_name in a database corresponds to three files in the database directory:

File

Purpose

tbl_name.frm

Table definition (form) file

tbl_name.MYD

Datafile

tbl_name.MYI

Index file

Each of these three file types is subject to corruption in various ways, but problems occur most often in data files and index files.

myisamchk works by creating a copy of the .MYD (data) file row by row. It ends the repair stage by removing the old .MYD file and renaming the new file to the original filename. If you use --quick, myisamchk does not create a temporary .MYD file, but instead assumes that the .MYD file is correct and only generates a new index file without touching the .MYD file. This is safe because myisamchk automatically detects if the .MYD file is corrupt and aborts the repair in this case. You can also give two --quick options to myisamchk. In this case, myisamchk does not abort on some errors (like duplicate key) but instead tries to resolve them by modifying the .MYD file. Normally the use of two --quick options is useful only if you have too little free disk space to perform a normal repair. In this case you should at least make a backup before running myisamchk.

How to check tables for errors

To check a MyISAM table, use the following commands:

myisamchk tbl_name

This finds 99.99% of all errors. What it can’t find is corruption that involves only the data file (which is very unusual). If you want to check a table, you should normally run myisamchk without options or with either the -s or --silent option.

myisamchk -m tbl_name

This finds 99.999% of all errors. It first checks all index entries for errors and then it reads through all rows. It calculates a checksum for all keys in the rows and verifies that the checksum matches the checksum for the keys in the index tree.

myisamchk -e tbl_name

This does a complete and thorough check of all data (-e means “extended check”). It does a check-read of every key for each row to verify that they indeed point to the correct row. This may take a long time on a big table with many keys. myisamchk will normally stop after the first error it finds. If you want to obtain more information, you can add the --verbose (-v) option. This causes myisamchk to keep going, up through a maximum of 20 errors. In normal usage, a simple myisamchk (with no arguments other than the table name) is sufficient.

myisamchk -e -i tbl_name

Like the previous command, but the -i option tells myisamchk to print some informational statistics, too.

How to repair tables

In the following section we only talk about using myisamchk on MyISAM tables (extensions .MYI and .MYD). If you are using ISAM tables (extensions .ISM and .ISD), you should use isamchk instead.

Starting with MySQL Version 3.23.14, you can repair MyISAM tables with the REPAIR TABLE command. See Section 4.4.5.

The symptoms of a corrupted table include queries that abort unexpectedly and observable errors such as these:

  • tbl_name.frm is locked against change.

  • Can’t find file tbl_name.MYI (Errcode: ###).

  • Unexpected end of file.

  • Record file is crashed.

  • Got error ### from table handler.

    To get more information about the error you can run perror ###. Here are the most common errors that indicate a problem with the table:

    shell> perror 126 127 132 134 135 136 141 144 145
    126 = Index file is crashed / Wrong file format
    127 = Record-file is crashed
    132 = Old database file
    134 = Record was already deleted (or record file crashed)
    135 = No more room in record file
    136 = No more room in index file
    141 = Duplicate unique key or constraint on write or update
    144 = Table is crashed and last repair failed
    145 = Table was marked as crashed and should be repaired

    Note that error 135, No more room in record file, is not an error that can be fixed by a simple repair. In this case you have to do:

    ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

In the other cases, you must repair your tables. myisamchk can usually detect and fix most things that go wrong.

The repair process involves up to four stages, described next. Before you begin, you should cd to the database directory and check the permissions of the table files. Make sure they are readable by the Unix user that mysqld runs as (and to you because you need to access the files you are checking). If it turns out you need to modify files, they must also be writable by you.

If you are using MySQL Versions 3.23.16 and above, you can (and should) use the CHECK and REPAIR commands to check and repair MyISAM tables. See Section 4.4.4, and Section 4.4.5.

The manual section about table maintenance includes the options to isamchk/myisamchk. See Section 4.4.6.

The following section is for the cases where the previous command fails or if you want to use the extended features that isamchk/myisamchk provides.

If you are going to repair a table from the command-line, you must first take down the mysqld server. Note that when you do mysqladmin shutdown on a remote server, the mysqld server will still be alive for a while after mysqladmin returns, until all queries are stopped and all keys have been flushed to disk.

Stage 1: Checking your tables

Run myisamchk *.MYI or myisamchk -e *.MYI if you have more time. Use the -s (silent) option to suppress unnecessary information.

If the mysqld server is done you should use the --update option to tell myisamchk to mark the table as ‘checked’.

You have to repair only those tables for which myisamchk announces an error. For such tables, proceed to Stage 2.

If you get weird errors when checking (such as out of memory errors), or if myisamchk crashes, go to Stage 3.

Stage 2: Easy safe repair

Note: If you want repairing to go much faster, you should add: -O sort_buffer=# -O key_buffer=# (where # is about 1/4 of the available memory) to all isamchk/myisamchk commands.

First, try myisamchk -r -q tbl_name (-r -q means “quick recovery mode”). This will attempt to repair the index file without touching the data file. If the data file contains everything that it should and the delete links point at the correct locations within the data file, this should work, and the table is fixed. Start repairing the next table. Otherwise, use the following procedure:

  1. Make a backup of the data file before continuing.

  2. Use myisamchk -r tbl_name (-r means “recovery mode”). This will remove incorrect records and deleted records from the data file and reconstruct the index file.

  3. If the preceding step fails, use myisamchk --safe-recover tbl_name. Safe recovery mode uses an old recovery method that handles a few cases that regular recovery mode doesn’t (but is slower).

If you get weird errors when repairing (such as out of memory errors), or if myisamchk crashes, go to Stage 3.

Stage 3: Difficult repair

You should only reach this stage if the first 16K block in the index file is destroyed or contains incorrect information, or if the index file is missing. In this case, it’s necessary to create a new index file. Do so as follows:

  1. Move the data file to some safe place.

  2. Use the table description file to create new (empty) data and index files:

    shell> mysql db_name
    mysql> SET AUTOCOMMIT=1;
    mysql> TRUNCATE TABLE table_name;
    mysql> quit

    If your SQL version doesn’t have TRUNCATE TABLE, use DELETE FROM table_name instead.

  3. Copy the old data file back onto the newly created data file. (Don’t just move the old file back onto the new file; you want to retain a copy in case something goes wrong.)

Go back to Stage 2. myisamchk -r -q should work now. (This shouldn’t be an endless loop.)

As of MySQL 4.0.2 you can also use REPAIR ... USE_FRM which performs the whole procedure automatically.

Stage 4: Very difficult repair

You should reach this stage only if the description file has also crashed. That should never happen, because the description file isn’t changed after the table is created:

  1. Restore the description file from a backup and go back to Stage 3. You can also restore the index file and go back to Stage 2. In the latter case, you should start with myisamchk -r.

  2. If you don’t have a backup but know exactly how the table was created, create a copy of the table in another database. Remove the new data file, then move the description and index files from the other database to your crashed database. This gives you new description and index files, but leaves the data file alone. Go back to Stage 2 and attempt to reconstruct the index file.

Table optimisation

To coalesce fragmented records and eliminate wasted space resulting from deleting or updating records, run myisamchk in recovery mode:

shell> myisamchk -r tbl_name

You can optimise a table in the same way using the SQL OPTIMIZE TABLE statement. OPTIMIZE TABLE does a repair of the table and a key analysis, and sorts the index tree to give faster key lookups. There is also no possibility of unwanted interaction between a utility and the server because the server does all the work when you use OPTIMIZE TABLE. See Section 4.5.1.

myisamchk also has a number of other options you can use to improve the performance of a table:

  • -S, --sort-index

  • -R index_num, --sort-records=index_num

  • -a, --analyze

For a full description of the option, see Section 4.4.6.1.

Setting Up a Table Maintenance Regimen

Starting with MySQL Version 3.23.13, you can check MyISAM tables with the CHECK TABLE command. See Section 4.4.4. You can repair tables with the REPAIR TABLE command. See Section 4.4.5.

It is a good idea to perform table checks on a regular basis rather than waiting for problems to occur. For maintenance purposes, you can use myisamchk -s to check tables. The -s option (short for --silent) causes myisamchk to run in silent mode, printing messages only when errors occur.

It’s also a good idea to check tables when the server starts up. For example, whenever the machine has done a reboot in the middle of an update, you usually need to check all the tables that could have been affected. (This is an “expected crashed table”.) You could add a test to safe_mysqld that runs myisamchk to check all tables that have been modified during the last 24 hours if there is an old .pid (process ID) file left after a reboot. (The .pid file is created by mysqld when it starts up and is removed when it terminates normally. The presence of a .pid file at system startup time indicates that mysqld terminated abnormally.)

An even better test would be to check any table whose last-modified time is more recent than that of the .pid file.

You should also check your tables regularly during normal system operation. At MySQL AB, we run a cron job to check all our important tables once a week, using a line like this in a crontab file:

35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI

This prints out information about crashed tables so that we can examine and repair them when needed.

As we haven’t had any unexpectedly crashed tables (tables that become corrupted for reasons other than hardware trouble) for a couple of years now (this is really true), once a week is more than enough for us.

We recommend that to start with, you execute myisamchk -s each night on all tables that have been updated during the last 24 hours, until you come to trust MySQL as much as we do.

Normally you don’t need to maintain MySQL tables that much. If you are changing tables with dynamic-size rows (tables with VARCHAR, BLOB, or TEXT columns) or have tables with many deleted rows, you may want to from time to time (once a month?) defragment/reclaim space from the tables.

You can do this by using OPTIMIZE TABLE on the tables in question. If you can take the mysqld server down for a while do:

isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index  -O sort_buffer_size=16M */*.MYI

Getting Information About a Table

To get a description of a table or statistics about it, use the commands shown here. We explain some of the information in more detail later:

myisamchk -d tbl_name

Runs myisamchk in “describe mode” to produce a description of your table. If you start MySQL server using the --skip-locking option, myisamchk may report an error for a table that is updated while it runs. However, because myisamchk doesn’t change the table in describe mode, there isn’t any risk of destroying data.

myisamchk -d -v tbl_name

To produce more information about what myisamchk is doing, add -v to tell it to run in verbose mode.

myisamchk -eis tbl_name

Shows only the most important information from a table. It is slow because it must read the whole table.

myisamchk -eiv tbl_name

This is like -eis, but tells you what is being done.

Example of myisamchk -d output:

MyISAM file:     company.MYI
Record format:   Fixed length
Data records:    1403698  Deleted blocks:         0
Recordlength:    226

table description:
Key Start Len Index   Type
1   2     8   unique  double
2   15    10  multip. text packed stripped
3   219   8   multip. double
4   63    10  multip. text packed stripped
5   167   2   multip. unsigned short
6   177   4   multip. unsigned long
7   155   4   multip. text
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

Example of myisamchk -d -v output:

MyISAM file:         company
Record format:       Fixed length
File-version:        1
Creation time:       1999-10-30 12:12:51
Recover time:        1999-10-31 19:13:01
Status:              checked
Data records:           1403698  Deleted blocks:              0
Datafile parts:         1403698  Deleted data:                0
Datafilepointer (bytes):      3  Keyfile pointer (bytes):     3
Max data file length: 3791650815  Max keyfile length: 4294967294
Recordlength:               226

table description:
Key Start Len Index   Type                  Rec/key     Root Blocksize
1   2     8   unique  double                      1 15845376      1024
2   15    10  multip. text packed stripped        2 25062400      1024
3   219   8   multip. double                     73 40907776      1024
4   63    10  multip. text packed stripped        5 48097280      1024
5   167   2   multip. unsigned short           4840 55200768      1024
6   177   4   multip. unsigned long            1346 65145856      1024
7   155   4   multip. text                     4995 75090944      1024
8   138   4   multip. unsigned long              87 85036032      1024
9   177   4   multip. unsigned long             178 96481280      1024
    193   1           text

Example of myisamchk -eis output:

Checking MyISAM file: company
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:  98%  Packed:   17%

Records:          1403698    M.recordlength:     226
Packed:             0%
Recordspace used:     100%   Empty space:          0%
Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

Example of myisamchk -eiv output:

Checking MyISAM file: company
Data records: 1403698   Deleted blocks:       0
- check file-size
- check delete-chain
block_size 1024:
index  1:
index  2:
index  3:
index  4:
index  5:
index  6:
index  7:
index  8:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:   9%  Packed:   17%

- check records and index references
[LOTS OF ROW NUMBERS DELETED]

Records:          1403698    M.recordlength:     226   Packed:             0%
Recordspace used:     100%   Empty space:          0%  Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

Here are the sizes of the data and index files for the table used in the preceding examples:

-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYM

Explanations for the types of information myisamchk produces are given here. The “keyfile” is the index file. “Record” and “row” are synonymous:

ISAM file

Name of the ISAM (index) file.

Isam-version

Version of ISAM format. Currently always 2.

Creation time

When the data file was created.

Recover time

When the index/data file was last reconstructed.

Data records

How many records are in the table.

Deleted blocks

How many deleted blocks still have reserved space. You can optimise your table to minimise this space. See Section 4.4.6.10.

Data file parts

For dynamic record format, this indicates how many data blocks there are. For an optimised table without fragmented records, this is the same as Data records.

Deleted data

How many bytes of non-reclaimed deleted data there are. You can optimise your table to minimise this space. See Section 4.4.6.10.

Data file pointer

The size of the data file pointer, in bytes. It is usually 2, 3, 4, or 5 bytes. Most tables manage with 2 bytes, but this cannot be controlled from MySQL yet. For fixed tables, this is a record address. For dynamic tables, this is a byte address.

Keyfile pointer

The size of the index file pointer, in bytes. It is usually 1, 2, or 3 bytes. Most tables manage with 2 bytes, but this is calculated automatically by MySQL. It is always a block address.

Max data file length

How long the table’s data file (.MYD file) can become, in bytes.

Max keyfile length

How long the table’s keyfile (.MYI file) can become, in bytes.

Recordlength

How much space each record takes, in bytes.

Record format

The format used to store table rows. The preceding examples use Fixed length. Other possible values are Compressed and Packed.

Table description

A list of all keys in the table. For each key, some low-level information is presented:

Key

This key’s number.

Start

Where in the record this index part starts.

Len

How long this index part is. For packed numbers, this should always be the full length of the column. For strings, it may be shorter than the full length of the indexed column because you can index a prefix of a string column.

Index

unique or multip (multiple). Indicates whether one value can exist multiple times in this index.

Type

What datatype this index part has. This is an ISAM datatype with the options packed, stripped or empty.

Root

Address of the root index block.

Blocksize

The size of each index block. By default this is 1024, but the value may be changed at compile time.

Rec/key

This is a statistical value used by the optimiser. It tells how many records there are per value for this key. A unique key always has a value of 1. This may be updated after a table is loaded (or greatly changed) with myisamchk -a. If this is not updated at all, a default value of 30 is given.

In the first preceding example, the 9th key is a multi-part key with two parts.

Keyblocks used

What percentage of the keyblocks are used. Because the table used in the examples had just been reorganised with myisamchk, the values are very high (very near the theoretical maximum).

Packed

MySQL tries to pack keys with a common suffix. This can only be used for CHAR/VARCHAR/DECIMAL keys. For long strings like names, this can significantly reduce the space used. In the third example, the fourth key is 10 characters long and a 60% reduction in space is achieved.

Max levels

How deep the B-tree for this key is. Large tables with long keys get high values.

Records

How many rows are in the table.

M.recordlength

The average record length. For tables with fixed-length records, this is the exact record length.

Packed

MySQL strips spaces from the end of strings. The Packed value indicates the percentage of savings achieved by doing this.

Recordspace used

What percentage of the data file is used.

Empty space

What percentage of the data file is unused.

Blocks/Record

Average number of blocks per record (that is, how many links a fragmented record is composed of). This is always 1.0 for fixed-format tables. This value should stay as close to 1.0 as possible. If it gets too big, you can reorganise the table with myisamchk. See Section 4.4.6.10.

Recordblocks

How many blocks (links) are used. For fixed format, this is the same as the number of records.

Deleteblocks

How many blocks (links) are deleted.

Recorddata

How many bytes in the data file are used.

Deleted data

How many bytes in the data file are deleted (unused).

Lost space

If a record is updated to a shorter length, some space is lost. This is the sum of all such losses, in bytes.

Linkdata

When the dynamic table format is used, record fragments are linked with pointers (4 to 7 bytes each). Linkdata is the sum of the amount of storage used by all such pointers.

If a table has been compressed with myisampack, myisamchk -d prints additional information about each table column. See Section 4.7.4, for an example of this information and a description of what it means.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required