MySQL服务时报1067错误，服务无法启动。
xxx.err错误日志发现有数据页损坏信息：
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 200.
出现上述现象是由于突然断电、强制关机、强制杀死MySQL进程等操作所导致的。
my.ini中的innodb_force_recovery参数(4-6)，使mysqld跳过恢复步骤，将mysqld 启动,将数据导出来然后重建数据库。
可以设置为1-6,大的数字包含前面所有数字的影响。
忽略检查到的corrupt页。
阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
不执行事务回滚操作。
不执行插入缓冲的合并操作。
不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
不执行前滚的操作。
注意
0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
MySQL的bin目录下的mysqlcheck.exe工具来尝试发现并修复MyISAM表的损坏数据页。
MyISAM数据页损坏，修复后，删除my.ini中的innodb_force_recovery参数，尝试启动。
InnoDB数据表发生了数据页损坏，需要导出数据，重新建库。
可以尝试运行
InnoDB出现了损坏，尝试使用冗余数据修复。
最后使用MySQL5\bin>mysqldump -uroot -pOSSDB123 databasename >e:\xxx.sql导出表结构和数据，使用load重建建库。也可以使用SELECT INTO OUTFILE从数据库转储你的表，通常以这种方法获取的数据是完好的。
下面是网上的一篇相关的文章：
表损坏的原因分析
mysql 表毁坏的常见原因：
、 服务器突然断电导致数据文件损坏。
、 强制关机，没有先关闭mysql 服务。
、 mysqld 进程在写表时被杀掉。
、 使用myisamchk 的同时，mysqld 也在操作表。
、 磁盘故障。
、 服务器死机。
、 mysql 本身的bug 。
表损坏的症状
一个损坏的表的典型症状如下：
、当在从表中选择数据之时，你得到如下错误：
Incorrect key file for table: '...'. Try to repair it
、查询不能在表中找到行或返回不完全的数据。
、Error: Table 'p' is marked as crashed and should be repaired 。
、打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。
预防 MySQL 表损坏
mysql 表损坏：
、定期使用myisamchk 检查MyISAM 表（注意要关闭mysqld ），推荐使用check table 来检查表（不用关闭mysqld ）。
、在做过大量的更新或删除操作后，推荐使用OPTIMIZE TABLE 来优化表，这样既减少了文件碎片，又减少了表损坏的概率。
、关闭服务器前，先关闭mysqld （正常关闭服务，不要使用kill -9 来杀进程）。
、使用ups 电源，避免出现突然断电的情况。
、使用最新的稳定发布版mysql ，减少mysql 本身的bug 导致表损坏。
、对于InnoDB 引擎，你可以使用innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。
、对磁盘做raid ，减少磁盘出错并提高性能。
、数据库服务器最好只跑mysqld 和必要的其他服务，不要跑其他业务服务，这样减少死机导致表损坏的可能。
、不怕万一，只怕意外，平时做好备份是预防表损坏的有效手段。
表损坏的修复
表可以采用以下步骤进行修复 ：
、 使用 reapair table 或myisamchk 来修复。
、 如果上面的方法修复无效，采用备份恢复表。
具体可以参考如下做法：
1 ：检查你的表
myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。
mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。
myisamchk 报告有错误的表。对这样的表，继续到阶段2 。
( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
2 ：简单安全的修复
myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。
myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。
( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
3 ：困难的修复
16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。
( 空) 数据文件和索引文件：
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。
REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
4 ：非常困难的修复
.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。
表可以采用下面的方法修复：
SELECT INTO OUTFILE 从从数据库转储你的表，通常以这种方法获取的大多数数据是完好的。即使这样，损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言，或者甚至使得InnoDB 前滚恢复崩溃。 尽管如此，你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行，以便你能转储你的表。例如：你可以在重启服务器之前，在选项文件的[mysqld] 节添加如下的行：
被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
1 (SRV_FORCE_IGNORE_CORRUPT)
SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作，不要计算表统计表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
InnoDB 把未完成的事务视为已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
innodb_force_recovery 被设置为大于0 的值时，InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.
DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程，然后设置innodb_force_recovery 为3 ，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
