谈谈SQL慢查询的解决思路

最近，在运维部及DBA同事的帮助和你们的共同努力下，对项目中的慢SQL进行了优化和修正，效果仍是很明显的，在此给你们点一个大大的赞。为了让咱们在SQL的处理上更为合理，造成可实践、可借鉴、可参考优化的方案，我在这里梳理一下慢SQL的解决思路，供你们参考。

慢SQL的系统表现

首先，咱们如何判别系统中遇到了SQL慢查询问题？我的认为慢SQL有以下三个特征：

1，数据库CPU负载高。通常是查询语句中有不少计算逻辑，致使数据库cpu负载。

2，IO负载高致使服务器卡住。这个通常和全表查询没索引有关系。

3，查询语句正常，索引正常可是仍是慢。若是表面上索引正常，可是查询慢，须要看看是否索引没有生效。

开启SQL慢查询的日志

若是你的系统出现了上述状况，而且你不是用的阿里云的RDS这样的产品，那么下一步就须要打开Mysql的慢查询日志来进一步定位问题。MySQL 提供了慢查询日志，这个日志会记录全部执行时间超过 long_query_time（默认是10s）的 SQL 及相关的信息。

要开启日志，须要在 MySQL 的配置文件 my.cnf 的 [mysqld] 项下配置慢查询日志开启，以下所示：

[mysqld]slow_query_log=1
slow_query_log_file=/var/log/mysql/log-slow-queries.log
long_query_time=2复制代码

在实际项目中，因为生成的慢查询的日志可能会特别大，分析起来不是很

方便，因此Mysql官方也提供了 mysqldumpslow 这个工具，方便咱们分析慢查询日志，感兴趣的同窗能够自行到Mysql官方进行查阅。

SQL调优

有些SQL虽然出如今慢查询日志中，但未必是其自己的性能问题，多是由于锁等待，服务器压力高等等。须要分析SQL语句真实的执行计划，而不是看从新执行一遍SQL时，花费了多少时间，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL，而后使用Explain工具来逐步调优，了解 MySQL 在执行这条数据时的一些细节，好比是否进行了优化、是否使用了索引等等。基于 Explain 的返回结果咱们就能够根据 MySQL 的执行细节进一步分析是否应该优化搜索、怎样优化索引。

关于索引的建立及优化原则，我的特别推荐美团点评技术团队的几点总结，讲得特别好，特意引用一下：

1. 最左前缀匹配原则，很是重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是创建(a,b,c,d)顺序的索引，d是用不到索引的，若是创建(a,b,d,c)的索引则均可以用到，a,b,d的顺序能够任意调整；

2. =和in能够乱序，好比a = 1 and b = 2 and c = 3 创建(a,b,c)索引能够任意顺序，mysql的查询优化器会帮你优化成索引能够识别的形式；

3. 尽可能选择区分度高的列做为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大咱们扫描的记录数越少，惟一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不一样，这个值也很难肯定，通常须要join的字段咱们都要求是0.1以上，即平均1条扫描10条记录；

4. 索引列不能参与计算，保持列“干净”，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，缘由很简单，b+树中存的都是数据表中的字段值，但进行检索时，须要把全部元素都应用函数才能比较，显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’);

5. 尽可能的扩展索引，不要新建索引。好比表中已经有a的索引，如今要加(a,b)的索引，那么只须要修改原来的索引便可。

一点总结

基于本文的思路，关于SQL慢查询的解决能够按照如下的步骤执行：

1. 打开慢日志查询，肯定是否有SQL语句占用了过多资源，若是是，在不改变业务原意的前提下，对insert、group by、order by、join等语句进行优化。

2. 考虑调整MySQL的系统参数： innodb_buffer_pool_size、innodb_log_file_size、table_cache等。

3. 肯定是不是由于高并发引发行锁的超时问题。

4. 若是数据量过大，须要考虑进一步的分库分表，能够参见以前的文章1和 文章2 。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上如下二维码便可