一点关于MySQL参数delay_key_write、myisam_recover_options的使用经验(二)

简单解释下delay_key_write,每次更新MyISAM表索引后不立即将更新flush到物理磁盘上，这些修改依然保留在内存中，直到这个表被关闭时再flush，ALL表示对所有的表都使用这一行为，ON表示对创建表时使用了delay_key_write的表使用这个功能。OFF表示不进行delay key write。而官方建议在使用delay_key_write时同时用myisam_recover_options这样才能保证数据一致性，否则，举个最简单的例子，索引数据一致都没flush到磁盘上，突然表被非正常关闭，等下次表被访问如果不进行相应的检测修复，那么就会出现数据文件与索引不一致的情况，这样就会导致数据不一致。

再简单解释下myisam_recover_options，default表示每次访问表时会先判断是否需要修复，但是不会强制修复（仅仅尝试从key cache中修复），backup表示修复时会先将老的数据文件先做个备份，force表示强制修复，具体用法见下图。

此时就大致可以确定是由于MySQL参数使用不合理导致的数据不一致问题，所以在使用MyISAM时如果配置了delay_key_write，就千万记得同时配置一个myisam_recover_options这样才可能防止数据不一致性的情况出现。那么我是怎么解决这个问题的呢？目前来说还是通过迁移后的MySQL配置参数环境保持与老环境一致，否则如果我现在强制加上参数myisam_recover_options，那么就会导致所有的表损坏，损坏之后恢复的唯一途径就是repair table，这会丢失数据（或者配置myisam_recover_options=force,backup，这个效果是跟repair table一样，且同时对将要修改的MYD文件做一个备份），因为对于重复键的行，如果是利用repair table去做的话，我无法干预MySQL留下其中具体的哪行，所以如果强行repair table虽然可以解决重复键错误，但是最终留下的哪行不一定是用户想要的那行数据。当然还有另外两种可行的方法，第一，咨询业务负责人后手工删除重复键中不需要的行。第二，强制repair table 然后将老的数据留一份做备份，然后用户端发现异常了再进行数据恢复，不过这个做法不可取，否则都会被用户投诉致死。

总之，都21世纪了，都5.6了，不要再用MyISAM了吧，我这是历史 系统，没办法，后期进行升级改造也是必须进行的。