最近刚接手一个项目，从业务端优化DB是最值得做的一件事。

   项目存在赶工的现象。很多功能和优化都放到了最后。当玩家都反应游戏卡的时候，大家都招架不住啦。。。。

   言归正传：对于含有TEXT字段类型的表，必须独立成一张表。

   有一张表，含有12个字段并包含mediumtext 的字段，这是让人最纠结的。刚上线的一段时间，其他表都在M级别，而含text类型的表已经到达23G！！！

   由于该表只是提供给前端战斗计算的数据，并且后期可能跟踪战斗记录。所以很多数据都是可以删除的。

   优化方案: 1、分表， 将该字段 独立成单表。应用端多一次查询（开发和DBA都要做修改）。

             2、删表， 定期额删除部分数据，并进行optimize (DBA一端就可以搞定)

             3、上NOSQL，用redis 这样的 KV存储系统，应该会更高效些。

             4、最优办法：对玩家战斗记录计算数据，保存在 memcached中，完全不需要DB（最优，技术要求最高的一个，）

   目前采用的是第二种方式，对于第四种方式，是因为应用端无法实现，（经常有手动清空内存个的情况，对此表示遗憾。）

   删除方式：写了一个存储过程，一部分一部分的去删除数据。这样可以避免slave因为一个大事务而拖死。

CREATE  PROCEDURE `del_sleep`(num int)   begin   declare a int default 1;   while a<=num do delete from user_fight_xml limit 100;   select sleep(1); set a=a+1;   end while;   end$$

  optimize table 回收空间，碎片整理的时候，提示以下信息：

note     | Table does not support optimize, doing recreate + analyze instead   status   | OK

  刚开始不解：为什么会替换为 recreate+analyze ，通过查询文档：

  对于MyISAM表来说：

  1、对于delete情况，会进行repair

  2、索引页排序

  3、表的更新为最新（the repair could not be accomplished by sorting the index）

  对于InnoDB来说，会被映射为 alter table，所以会是 recreate + analyze的情况

  如果不想写入slave的话，可以使用 NO_WRITE_TO_BINLOG 关键字！

本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1080533，如需转载请自行联系原作者