今天经历了一次痛苦的mysql表修复操作，感觉还是比较有意义的，写出来供大家参考
某客户的mysql出现异常，经常自动停止，err中如下记录

090614 2:47:09 [Note] D:\MySQL\bin\mysqld-nt: ready for connections.
 Version: '5.0.17-nt' socket: '' port: 3306 MySQL Community Edition (GPL)
 InnoDB: Error: page n:o stored in the page read in is 3755989959, should be 19641!
 InnoDB: Database page corruption on disk or a failed
 InnoDB: file read of page 19641.
 InnoDB: You may have to recover from a backup.


由于客户对mysql不是很了解，也没有对对应的库进行过备份，所以也就没有办法从备份恢复了，之前也有碰到过，不过当时是一条记录的问题，判断方式就是用mysqldump导处数据时肯定在固定的记录上停止，这个当时简单的处理就是把对应记录删除后手动添加上去了，这次的却比较复杂，尝试先备份数据，每次mysqldump都会出错，错误点不是在同一个表，只导一个表时id也不一样，这样就怀疑库问题了，由于使用的innodb引擎，按照网上的说法“innodb表损坏，可能导致mysqld不断地crash。在用户访问到有问题数据的位置就可能导致crash。而mysql目前没有修复innodb表的工具，只能用innodb_force_recovery=1，避免在导出数据时再crash。”在my.cnf中设置好后重启库，再用mysqldump或者select *把出问题的表导出来。然后重新导入（删除原表）。如果数据量大的话，就得慢慢等了。还好比较幸运的是，增加强制修复参数后，完整地导出了数据。其他工作就是从新创建数据库并导入数据了。在增加强制修复参数后发现err日志大小飙增,比数据库本身都还大

InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
 InnoDB: about forcing recovery.
 InnoDB: Ending processing because of a corrupt database page.
 090615 15:35:41 InnoDB: Database was not shut down normally!
 InnoDB: Starting crash recovery.
 InnoDB: Reading tablespace information from the .ibd files...
 InnoDB: Restoring possible half-written data pages from the doublewrite
 InnoDB: buffer...
 090615 15:35:42 InnoDB: Starting log scan based on checkpoint at
 InnoDB: log sequence number 0 1804286759.
 InnoDB: Doing recovery: scanned up to log sequence number 0 1804286759
 InnoDB: Last MySQL binlog file position 0 0, file name 
 090615 15:35:42 InnoDB: Started; log sequence number 0 1804286759
 InnoDB: !!! innodb_force_recovery is set to 1 !!!
 090615 15:35:42 [Note] D:\MySQL\bin\mysqld-nt: ready for connections.
 Version: '5.0.17-nt' socket: '' port: 3306 MySQL Community Edition (GPL)



这里还碰到一个问题，在加了强制修复参数后，如果对数据库进行写入参数会出现：
ERROR 1030 (HY000): Got error -1 from storage engine


不过发现高兴地过早了，新导入的数据还是有问题，这样就怀疑数据库本身故障了，由于本身只提供了一个应用程序的应用，也只有一个用户库，之前已经备份好了，卸载mysql，重新导入OK。


导入优化：

mysql恢复的导入过程是一个痛苦的过程，30多万条记录，导了2个多小时，后同事在网上找到一个方法，在导出时合理使用几个参数，可以大大加快导入的速度。
-e 使用包括几个VALUES列表的多行Insert语法;
-max_allowed_packet=XXX 客户端/服务器之间通信的缓存区的最大大小;
-net_buffer_length=XXX TCP/IP和套接字通信缓冲区大小,创建长度达net_buffer_length的行。

注意：max_allowed_packet和net_buffer_length不能比目标数据库的设定数值大，否则可能出错。

首先确定目标库的参数值,这个mysql版本相同的默认都相同，当然也可以在mysql.cnf中修改

mysql> show variables like 'max_allowed_packet';
 +--------------------+---------+
 | Variable_name | Value |
 +--------------------+---------+
 | max_allowed_packet | 1048576 |
 +--------------------+---------+
 1 row in set (0.00 sec)
 mysql> show variables like 'net_buffer_length';
 +-------------------+-------+
 | Variable_name | Value |
 +-------------------+-------+
 | net_buffer_length | 16384 |
 +-------------------+-------+
 1 row in set (0.00 sec)




根据参数值书写mysqldump命令，如：

C:\Documents and Settings\Administrator>mysqldump -uusername -ppassword --def
 ault-character-set=gbk --opt --add-drop-table databasename -e --max_allowed_pac
 ket=1048576 --net_buffer_length=16384 > D:/090615.sql


之前2个多小时才能导入的sql现在7分钟内就可以完成了。真的很惊讶！！