mysql innodb 导入_MySQL?innodb表修复以及导入优化

今天经历了一次痛苦的mysql表修复操作，感觉还是比较有意义的，写出来供大家参考

某客户的mysql出现异常，经常自动停止，err中如下记录

090614 2:47:09 [Note] D:\MySQL\bin\mysqld-nt: ready forconnections.

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 alsohttp://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 thedoublewrite

InnoDB: buffer...

090615 15:35:42 InnoDB: Starting log scan based on checkpointat

InnoDB: log sequence number 0 1804286759.

InnoDB: Doing recovery: scanned up to log sequence number 01804286759

InnoDB: Last MySQL binlog file position 0 0, file name

090615 15:35:42 InnoDB: Started; log sequence number 01804286759

InnoDB: !!! innodb_force_recovery is set to 1 !!!

090615 15:35:42 [Note] D:\MySQL\bin\mysqld-nt: ready forconnections.

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=XXXTCP/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分钟内就可以完成了。真的很惊讶！！

对于这些参数可以看看 mysqldump的帮助和以下的文章

http://www.ixdba.net/article/53/243.html

http://dev.mysql.com/doc/refman/5.1/zh/using-mysql-programs.html