谈谈Mysql优化心得体会

谈谈Mysql优化心得体会

类别：技术 | 浏览(1134) | 评论 (1) 2009-09-16 12:08

 标签： 总结   

最近发现系统有点慢,于是认真的分析了一下慢日志,发现有些慢日志还真不少,有些还是10秒以上．感觉单从Ｍysql 查询语句上，还是可以做优化的．简单记录下，也当做日志吧．大牛，大虾们见笑了． 1.Mysql 查询总数问题    select count(1) from blog_art 与 select count(1) from blog_art where userid > 0 ; //　查询文章总数　userid 上有索引    大家都知道，像这样的查询，Ｍysql只能做全表扫描.    我们这里　用的是 InnoDB 引挚．原本以为，这两条性能差不多，可以经过测试，第二条语句快得多．经查Ｍysql官方文档，大致是这么写的:      innodb 的 clustered index 是把 primary key 以及 row data 保存在一起的，而 secondary index 则是单独存放，然后有个指针指向    primary key。因此，需要进行 count(*) 统计表记录总数时，利用 secondary index 扫描起来，显然更快 2.Mysql大表折成小表    例如下一条Ｓql语句    select * from blog_art  where checkFlag='1' and  deleteFlag='1' order by createTime desc limit 10; //查询审核通过的文章且没有被删除的文章，时间倒序排 (这个表，那时数据在90万左右，这条Ｓql语句数据在 5０万左右排序)    这个Ｓql 语句总用了 300秒时间. 做了一次copy 临时表，再排序．50万数据排序（有内容大字段),可想而知，是多少的慢．而且就这么一条Ｓql语句，就会造成ＩＯ堵塞。   1.解决方法，建立 checkFlag,deleteFlag,createTime  desc 的一个复合索引．但对于现在的系统，建这个索引感觉不是最好解决方案，因为这个Ｓql语句是动态的，有可能还有一些其它的一些条件，建复合索引，只能解决这一个组合方式，并不能从根本上解决问题． 　２.给Ｍysql 廋身. 因为  blog_art   有内容大字段，且数据有90万之多，我们暂时把它称为大表.(大牛，大虾们见笑了，我知道在你们眼里1000万也不算什么大表). 我们建另一个表如 blog_simpleArt ，除了大字段没有外，其它字段都有，包含一些索引。 (blog_simpleArt与blog_art的同步用mysql的触发器同步)      select * from blog_simpleArt   where checkFlag='0' and  deleteFlag='1' order by createTime desc limit 10; //修改后，这条Ｓql语句不到2秒时间。    select * from blog_art where id in （上一句前10ＩＤ) order by createTime desc ; //在这里也用到了第3点. 可以把一条SQL语句拆成多成SQL语句,有可能性能会更好 ３.可以把一条SQL语句拆成多成SQL语句,有可能性能会更好 　还是接上面修改后的这条语句 select * from blog_simpleArt   where checkFlag='0' and  deleteFlag='1' order by createTime desc limit 10;    修改后，感觉2秒还是太长了点, ，(还是要做了一次临时表排序，能不能使排序的内容再少点呢，越少速度应该越快) 性能能不能再有所提升呢？想了想，有了    把这条Ｓql 语句拆成两条Ｓql语句，看看会怎么样，说干就干.    1. select id from blog_simpleArt   where checkFlag='0' and  deleteFlag='1' order by createTime desc limit 10;     2. select * from  blog_simpleArt where id in ( 上一句Ｓql 的10ＩＤ)  order by createTime desc;    ＯＫ，成功，性能在1秒以下.    3. select * from blog_art where id in （上一句前10ＩＤ) order by createTime desc ; ４.Mysql 尽量只查询需要的数据 　这点，地球人都知道了。就不说了 5.Mysql 排序问题    排序问题，不管是什么数据库。有时候都是个头痛的问题。大部分排序要求都是逻辑的需要,是必须的(业务逻辑是最没有逻辑的逻辑)    大家都知道，一般情况下，一个Ｓql语句，只能用到一条索引(复合索引也看作是一条索引). 所以很多时候，要不就建一条复合索引，以提升性能，但如果这样，有可能需要建很多类似的索引，要知道，维护一个索引的成本是相当高的。 　现在对于我们的系统来说，因为数据量还真不是太大，所以应用 以上 几点，现在性能还是相当不错的 6.面对以后大数据量的一些想法    以后数据量大了之后，   数据库：有可能会考虑采用(主从)读写分离，主主(读写分离),Ｍysql的分区，分库等等 应用服务：采用集群方案，用Cach （现在没有用） http://blog.china.com.cn/dengshucai/art/1201258.html