最近刚接手一个项目，从业务端优化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，如需转载请自行联系原作者