MySQL - text 性能优化--记录一

  1. 云栖社区>
  2. 博客>
  3. 正文

MySQL - text 性能优化--记录一

像教授 2017-11-26 20:22:00 浏览997
展开阅读全文

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

网友评论

登录后评论
0/500
评论
像教授
+ 关注