MySQL的Innodb表修复
前一段时间遇到这样一个问题，突然有一天在做数据库备份的时候出现了#2013 - Lost connection to MySQL server at 'reading initial communication packet', system error: 0，注意我的标红部分。因为不同的错误代码可能原因是不同的。即使是我这个问题，网上找到的原因也有几种。
到网站去搜，刚开始的结果是说linux的hosts.allow里面应该加一行mysqld:ALL:ALLOW。意思就是，linux的远程服务没有把mysql加到里面。但问题就来了，以前我运行都好好的呢。死马且当活马医吧。加上试试，不行。在my.ini里面加上skip-name-resolve？没用！my.ini里面有个bind-address=127.0.0.1？没有啊！
后来还是着急备份数据，只能试试其他表行不行。其他表都没问题，唯独一张表，也就是文章表，备份出现问题。问google（以前都是问baidu，但还是google靠谱啊），说是表出现问题了，这个问题后来得知或是因为数据量过大，或是因为mysql的bug。但是怎么修复呢，checktable？那是对myisam，如果对innodb的数据库，会显示一个当前表的storeage（数据库引擎）不支持当前操作。其实网上搜如果修复innodb的表有很多。但最权威的还是mysql官网上的。里面这样写的，英文不好直接看我翻译。
13.2.6.2. Forcing InnoDB Recovery

If there is database page corruption, you may want to dump your tables from the database with SELECT ... INTO OUTFILE. Usually, most of the data obtained in this way is intact. However, it is possible that the corruption might cause SELECT * FROM tbl_name statements or InnoDB background operations to crash or assert, or even cause InnoDB roll-forward recovery to crash. In such cases, you can use the innodb_force_recovery option to force the InnoDB storage engine to start up while preventing background operations from running, so that you are able to dump your tables. For example, you can add the following line to the [mysqld] section of your option file before restarting the server:

[mysqld]
innodb_force_recovery = 4

innodb_force_recovery is 0 by default (normal startup without forced recovery) The permissible nonzero values for innodb_force_recovery follow. A larger number includes all precautions of smaller numbers. If you are able to dump your tables with an option value of at most 4, then you are relatively safe that only some data on corrupt individual pages is lost. A value of 6 is more drastic because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures.

    1 (SRV_FORCE_IGNORE_CORRUPT)

    Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.

    2 (SRV_FORCE_NO_BACKGROUND)

    Prevent the main thread from running. If a crash would occur during the purge operation, this recovery value prevents it.

    3 (SRV_FORCE_NO_TRX_UNDO)

    Do not run transaction rollbacks after recovery.

    4 (SRV_FORCE_NO_IBUF_MERGE)

    Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate table statistics.

    5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

    Do not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed.

    6 (SRV_FORCE_NO_LOG_REDO)

    Do not do the log roll-forward in connection with recovery.

The database must not otherwise be used with any nonzero value of innodb_force_recovery. As a safety measure, InnoDB prevents users from performing INSERT, UPDATE, or DELETE operations when innodb_force_recovery is greater than 0.

You can SELECT from tables to dump them, or DROP or CREATE tables even if forced recovery is used. If you know that a given table is causing a crash on rollback, you can drop it. You can also use this to stop a runaway rollback caused by a failing mass import or ALTER TABLE. You can kill the mysqld process and set innodb_force_recovery to 3 to bring the database up without the rollback, then DROP the table that is causing the runaway rollback.
我的翻译
13.2.6.2. 强制执行innodb恢复
如果你想从数据库中备份你的数据。通常，大多数获得的数据是完整的。但是，不排除你在执行SELECT * FROM tbl_name或者执行InnoDB