谈谈Mysql优化心得体会

最新推荐文章于 2022-04-06 21:27:30 发布

militala

最新推荐文章于 2022-04-06 21:27:30 发布

阅读量1.4k

点赞数

分类专栏：新手:SQL/MYSQL基础文章标签： mysql 优化 blog sql 数据库文档

新手:SQL/MYSQL基础专栏收录该内容

13 篇文章 0 订阅

订阅专栏

谈谈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