最近刚接手一个项目，从业务端优化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 ，通过查询文档：
http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html
对于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，如需转载请自行联系原作者
