#### 13.7.3.5 REPAIR TABLE Statement

[]()

```
REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]
```

[`REPAIR TABLE`](repair-table.html) repairs a possibly corrupted table, for certain storage engines only.

 This statement requires [`SELECT`](privileges-provided.html#priv_select) and [`INSERT`](privileges-provided.html#priv_insert) privileges for the table.

 Although normally you should never have to run [`REPAIR TABLE`](repair-table.html), if disaster strikes, this statement is very likely to get back all your data from a `MyISAM` table. If your tables become corrupted often, try to find the reason for it, to eliminate the need to use [`REPAIR TABLE`](repair-table.html). See [Section B.3.3.3, “What to Do If MySQL Keeps Crashing”](crashing.html), and [Section 16.2.4, “MyISAM Table Problems”](myisam-table-problems.html).

[`REPAIR TABLE`](repair-table.html) checks the table to see whether an upgrade is required. If so, it performs the upgrade, following the same rules as [`CHECK TABLE ... FOR UPGRADE`](check-table.html). See [Section 13.7.3.2, “CHECK TABLE Statement”](check-table.html), for more information.

Important

* Make a backup of a table before performing a table repair operation; under some circumstances the operation might cause data loss. Possible causes include but are not limited to file system errors. See [Chapter 7, *Backup and Recovery*](backup-and-recovery.html).

* If the server exits during a [`REPAIR TABLE`](repair-table.html) operation, it is essential after restarting it that you immediately execute another [`REPAIR TABLE`](repair-table.html) statement for the table before performing any other operations on it. In the worst case, you might have a new clean index file without information about the data file, and then the next operation you perform could overwrite the data file. This is an unlikely but possible scenario that underscores the value of making a backup first.

* In the event that a table on the source becomes corrupted and you run [`REPAIR TABLE`](repair-table.html) on it, any resulting changes to the original table are *not* propagated to replicas.

[]()[]()

* [REPAIR TABLE Storage Engine and Partitioning Support](repair-table.html#repair-table-support)

* [REPAIR TABLE Options](repair-table.html#repair-table-options)

* [REPAIR TABLE Output](repair-table.html#repair-table-output)

* [Table Repair Considerations](repair-table.html#repair-table-table-repair-considerations)

##### REPAIR TABLE Storage Engine and Partitioning Support

[]()[]()

[`REPAIR TABLE`](repair-table.html) works for [`MyISAM`](myisam-storage-engine.html), [`ARCHIVE`](archive-storage-engine.html), and [`CSV`](csv-storage-engine.html) tables. For [`MyISAM`](myisam-storage-engine.html) tables, it has the same effect as [**myisamchk --recover *`tbl_name`***](myisamchk.html) by default. This statement does not work with views.

[`REPAIR TABLE`](repair-table.html) is supported for partitioned tables. However, the `USE_FRM` option cannot be used with this statement on a partitioned table.

 You can use `ALTER TABLE ... REPAIR PARTITION` to repair one or more partitions; for more information, see [Section 13.1.9, “ALTER TABLE Statement”](alter-table.html), and [Section 24.3.4, “Maintenance of Partitions”](partitioning-maintenance.html).

##### REPAIR TABLE Options

[]()

* `NO_WRITE_TO_BINLOG` or `LOCAL`

   By default, the server writes [`REPAIR TABLE`](repair-table.html) statements to the binary log so that they replicate to replicas. To suppress logging, specify the optional `NO_WRITE_TO_BINLOG` keyword or its alias `LOCAL`.

* `QUICK`

   If you use the `QUICK` option, [`REPAIR TABLE`](repair-table.html) tries to repair only the index file, and not the data file. This type of repair is like that done by [**myisamchk --recover --quick**](myisamchk.html).

* `EXTENDED`

   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**](myisamchk.html).

* `USE_FRM`

   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 data dictionary. This kind of repair cannot be done with [**myisamchk**](myisamchk.html).

  Caution

   Use the `USE_FRM` option *only* if you cannot use regular `REPAIR` modes. Telling the server to ignore the `.MYI` file makes important table metadata stored in the `.MYI` unavailable to the repair process, which can have deleterious consequences:

  * The current `AUTO_INCREMENT` value is lost.

  * The link to deleted records in the table is lost, which means that free space for deleted records remains unoccupied thereafter.

  * The `.MYI` header indicates whether the table is compressed. If the server ignores this information, it cannot tell that a table is compressed and repair can cause change or loss of table contents. This means that `USE_FRM` should not be used with compressed tables. That should not be necessary, anyway: Compressed tables are read only, so they should not become corrupt.

   If you use `USE_FRM` for a table that was created by a different version of the MySQL server than the one you are currently running, [`REPAIR TABLE`](repair-table.html) does not attempt to repair the table. In this case, the result set returned by [`REPAIR TABLE`](repair-table.html) contains a line with a `Msg_type` value of `error` and a `Msg_text` value of `Failed repairing incompatible .FRM file`.

   If `USE_FRM` is used, [`REPAIR TABLE`](repair-table.html) does not check the table to see whether an upgrade is required.

##### REPAIR TABLE Output

[]()

[`REPAIR TABLE`](repair-table.html) returns a result set with the columns shown in the following table.

|  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`](repair-table.html) 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`. For a `MyISAM` table, if you do not get `OK`, you should try repairing it with [**myisamchk --safe-recover**](myisamchk.html). ([`REPAIR TABLE`](repair-table.html) does not implement all the options of [**myisamchk**](myisamchk.html). With [**myisamchk --safe-recover**](myisamchk.html), you can also use options that [`REPAIR TABLE`](repair-table.html) does not support, such as [`--max-record-length`](myisamchk-repair-options.html#option_myisamchk_max-record-length).)

[`REPAIR TABLE`](repair-table.html) table catches and throws any errors that occur while copying table statistics from the old corrupted file to the newly created file. For example. if the user ID of the owner of the `.MYD` or `.MYI` file is different from the user ID of the [**mysqld**](mysqld.html) process, [`REPAIR TABLE`](repair-table.html) generates a "cannot change ownership of the file" error unless [**mysqld**](mysqld.html) is started by the `root` user.

##### Table Repair Considerations

[`REPAIR TABLE`](repair-table.html) upgrades a table if it contains old temporal columns in pre-5.6.4 format ([`TIME`](time.html), [`DATETIME`](datetime.html), and [`TIMESTAMP`](datetime.html) columns without support for fractional seconds precision) and the [`avoid_temporal_upgrade`](server-system-variables.html#sysvar_avoid_temporal_upgrade) system variable is disabled. If [`avoid_temporal_upgrade`](server-system-variables.html#sysvar_avoid_temporal_upgrade) is enabled, [`REPAIR TABLE`](repair-table.html) ignores the old temporal columns present in the table and does not upgrade them.

 To upgrade tables that contain such temporal columns, disable [`avoid_temporal_upgrade`](server-system-variables.html#sysvar_avoid_temporal_upgrade) before executing [`REPAIR TABLE`](repair-table.html).

 You may be able to increase [`REPAIR TABLE`](repair-table.html) performance by setting certain system variables. See [Section 8.6.3, “Optimizing REPAIR TABLE Statements”](repair-table-optimization.html).

