应用程序则报主键冲突,数据不到2000W行myisamchk -r xxx.MYI的结果
Wrong bytesec:   0-  0-  0 at  661098824; Skipped
Wrong bytesec:   0-  0-  0 at  674406892; Skipped
Wrong bytesec:   0-  0-  0 at  674410184; Skipped
Wrong bytesec:   0-  0-  0 at  674451712; Skipped

解决方案 »

  1.   

    REPAIR TABLE是可以啊,但是为啥老是出这个错呢?最近写数据较多
      

  2.   

    myisam 数据表很容易损坏 原因有很多 如:
    ·  mysqld进程在写中间被杀掉。 · 发生未预期的计算机关闭(例如,计算机被关闭)。 · 硬件故障。 · 你可以同时在正被服务器修改的表上使用外部程序(如myisamchk)。 · MySQL或MyISAM代码的软件缺陷。 一个损坏的表的典型症状如下: · 当在从表中选择数据之时,你得到如下错误: · Incorrect key file for table: '...'. Try to repair it · 查询不能在表中找到行或返回不完全的数据。 
    如果你的表变得频繁损坏,你应该试着确定为什么会这样的原因。要明白的最重要的事是表变得损坏是不是因为服务器崩溃的结果。你可以在错误日志中查找最近的restarted mysqld消息来早期验证这个。如果存在这样一个消息,则表损坏是服务器死掉的一个结果是很有可能的。否则,损坏可能在正常操作中发生。
      

  3.   

    是不是你服务启异常重启的原因啊?一般来说,myisam 的应该定时做 repair..9.6. 建立表维护计划
    定期对表进行检查而非等到问题出现后再检查数据库表是一个好主意。检查和修复MyISAM表的一个方式是使用CHECK TABLE和REPAIR TABLE语句。参见13.5.2.3节,“CHECK TABLE语法”和13.5.2.6节,“REPAIR TABLE语法”。检查表的另一个方法是使用myisamchk。为维护目的,可以使用myisamchk -s检查表。-s选项(简称--silent)使myisamchk以沉默模式运行,只有当错误出现时才打印消息。在服务器启动时检查表是一个好主意。例如,无论何时机器在更新当中重新启动了,你通常需要检查所有可能受影响的表。(即“预期的破坏了的表”)。要想自动检查MyISAM表,用--myisam-recover选项启动服务器。一个更好的测试将是检查最后修改时间比“.pid”文件新的表。你还应该在正常系统操作期间定期检查表。在MySQL AB,我们运行一个cron任务,每周一次检查所有重要的表,使用“crontab”文件中这样的行:35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
    可以打印损坏的表的信息,以便我们在需要时能够检验并且修复它们。多年了我们还没有发现(的确是真的)都没有任何意外损坏的表时(由于除硬件故障外的其它原因造成损坏的表),每周一次对我们是足够了。我们建议现在开始,你对所有最后24小时内被更新了的表每晚都执行myisamchk -s,直到你变得象我们那样信任MySQL。一般情况,MySQL表很少需要维护。如果你用动态大小的行更改MyISAM表(含VARCHAR、BLOB或TEXT列的表)或有删除了许多行的表,你可能想要不时地(每月一次)整理/组合表的空间。可以对有问题的表执行OPTIMIZE TABLE来优化。或者是,如果可以停一会mysqld服务器,进入数据目录,当服务器停止时使用该命令:shell> myisamchk -r -s --sort-index -O sort_buffer_size=16M */*.MYI
      

  4.   

    优化一下表就可以减少出错的概率。
    OPTIMIZE table 表名;