一个关于mysql崩溃的问题，很神奇！

Question

table_log,innodb表，有一个存储过程abc，用于从table_log表中读取数据，自服务器启动开始，就有一个程序往table_log中insert数据，但并不是一直lock这个表，就是断断续续的insert，从Apache日志中看，abc被服务器运行时，经常是“Deadlock found when trying to get lock; try restarting transaction”，在重复了大概7、8次左右，突然就“query error[2010-12-08 15:32:01][../dbClient/MySqlDatabase.cpp:165] Can't connect to local MySQL server through socket '/tmp/mysql.sock'”了，然后，Apache日志中断了50分钟没有没有任何记录，从系统日志syslog上看，在出现这个问题的时候，没有任何错误信息，还在一直运行着各种脚本，而就在50分钟后Apache日志有信息的同时（当然，这时候还是一堆的“ Can't connect to local MySQL server through socket '/tmp/mysql.sock”），系统日志就出现了这样的信息：
Dec  8 15:31:58 abc mysqld[2687]: InnoDB: Database page corruption on disk or a failed
Dec  8 15:31:58 abc mysqld[2687]: InnoDB: file read of page 83999.
Dec  8 15:31:58 abc mysqld[2687]: InnoDB: You may have to recover from a backup.
Dec  8 15:31:58 abc mysqld[2687]: 101208 15:31:58  InnoDB: Page dump in ascii and hex (16384 bytes):
Dec  8 15:31:58 abc mysqld[2687]:  len 16384; hex 85f7c6c900。。一堆dump码之后，force_recovery=1，select * into outfile，drop掉这个表，重建这个表，导入数据，修复了，期间看不出有任何重启或者拔电的迹象，这个问题能是因为什么呢？磁盘就因为几次死锁，就挂掉了？？？

Answer 1

用myisam存储引擎来做日志表，可以并行插入

Answer 2

修复之后，也有锁表现象，但是我优化了查询方法，可能现在运行abc的时候会比之前快很多，不过崩溃现象确实就是没出现过了…

Answer 3

是的，不过我看mysql文档，MYISAM只有在只进行插入和查询操作的表上可以进行同时的插入和查询，但是如果这个表把中间，或者之前的数据删除了的话，导致磁盘有自由空间的时候，则不能同时插入与查询了，这时就必须运行optimize table或者等那些自由空间全都被填满的时候才能再次进行同时的查询与插入，我的这个表是设计成允许删除指定记录的，所以暂时不打算改成这样，我之前也尝试过改为MYISAM，不过结果就是，在耗时查询的时候，插入的数据一直在累积…
我也是一知半解，但现象确实如此…

Answer 4

MYISAM在处理插入和查询并发的时候，效率不差。有个参数可以指定插入永远插到文件末尾，而不是中间的空隙位置。INNODB在并发方面比MYISAM好，因为它的锁定粒度更小，行锁定的。你优化查询后，锁表的情况就没发生了，说明原来的查询有问题。一般碰到这样的问题，首先考虑优化查询是没错的。

Answer 5

不是没有死锁现象，而是少了，但是不崩溃了，这个崩溃的原因您有啥想法么？
似乎确实可以考虑考虑MYISAM，不过这个文件碎片怕在大量的插入和删除之后变得很客观啊，我这个表是不打算随便就optimize table的，因为是有很多很大的表，而且这个操作耗时应该不小吧…

Answer 6

这个怎么看呢…反正基本上CPU都在2、30%，内存也就是30%左右吧
用的Linux系统是gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) i686 GNU/Linux 
文件系统是JFS

Answer 7

刚了解了一下，经常有大宗的磁盘操作，这个时候CPU是会占到100%，而且比较经常

Answer 8

这个问题有没有什么办法可以让系统自动修复呢？就是让这个文件好起来？
而不是人去innodb_force_recovery=xxx的，然后做一堆操作？