mysql杂谈
两年前规划 news database 时，只做了千万级的设计，把 news 索引表和 newscontent 内容表分开，这样 news 索引表的效率很高，而 newscontent 除了偶尔读写，其他时候仅为存诸、备份，字段也很简单，一直都很高效。
关于 news database，曾经有一次让啊土（我们 Team 的一名程序员）误操作，把几百万条数据记录删除了，他的恢复脚本里面首面有 drop table 行为，当时被我严重教育了一番，后来把权限控制的比较严格一些，从此没再发生这种严重错误。
然而两年过去了，千万条数据记录也达到了，发生 mysql index 错误，需要使用 myisamchk 进行修复，发现分区 541G 已经使用了 458G，使用 myisamchk -r newscontent 修复不够空间，使用 -q 参数又不放心，只好接个 1.5TB 的 SATA 外接硬盘上去，把文件拷贝出来等修复完再传回去。
是时候对 news 数据库做上亿级规划的时候了，得把 newscontent 表再重新设计，规划一下，拆分成多张表，相对固定比如 [0-9]、[09-99]、[A-Z] 或按 [YYYYMM] 分表存诸。
Update：9个小时后，我放弃了把 newscontent.MYD 数据库文件通过网络传到 1.5TB USB/SATA 硬盘上再修复的做法，因为只完成了1/2不到，即便全部传完，再过9个小时，我才能开始修复，而修复时间，又将过去多少时间？因此，我又改用了 myisamchk -r -q newscontent 的方法，同时使用 renice 把优先级设到最大，让他去吧！