温馨提示:本文大概 3000 字,阅读需要 5 分钟。
可以使用 sar
命令,top
命令查看当前系统状态。
也可以通过 Prometheus、Grafana
等监控工具观察服务器状态。(感兴趣的可以翻看我之前的文章)
冗长的SQL都好理解,一段SQL太长阅读性肯定会差,而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手,如下所示:
执行计划告诉我们本次查询走了全表扫描 Type=ALL
,rows很大(9950400)基本可以判断这是一段"有味道"的SQL。
获取问题SQL
不同数据库有不同的获取方法,以下为目前主流数据库的慢查询SQL获取工具
SQL编写技巧
SQL编写有以下几个通用的技巧:
• 合理使用索引
• 使用UNION ALL替代UNION
• 避免select * 写法
• JOIN字段建议建立索引
• 避免复杂SQL语句
• 避免where 1=1写法
• 避免order by rand()类似写法
SQL优化
执行计划
完成SQL优化一定要先读执行计划,执行计划会告诉你哪些地方效率低,哪里可以需要优化。我们以MYSQL为例,看看执行计划是什么。(每个数据库的执行计划都不一样,需要自行了解)explain sql
id | 每个被独立执行的操作标识,标识对象被操作的顺序,id值越大,先被执行,如果相同,执行顺序从上到下 |
select_type | 查询中每个select 字句的类型 |
table | 被操作的对象名称,通常是表名,但有其他格式 |
partitions | 匹配的分区信息(对于非分区表值为NULL) |
type | 连接操作的类型 |
possible_keys | 可能用到的索引 |
key | 优化器实际使用的索引(最重要的列) 从最好到最差的连接类型为 const 、eq_reg 、ref 、range 、index 和 ALL 。当出现 ALL 时表示当前SQL出现了“坏味道” |
key_len | 被优化器选定的索引键长度,单位是字节 |
ref | 表示本行被操作对象的参照对象,无参照对象为NULL |
rows | 查询执行所扫描的元组个数(对于innodb,此值为估计值) |
filtered | 条件表上数据被过滤的元组个数百分比 |
extra | 执行计划的重要补充信息,当此列出现 Using filesort , Using temporary 字样时就要小心了,很可能SQL语句需要优化 |
接下来我们用一段实际优化案例来说明SQL优化的过程及优化技巧。
优化案例
总结
这篇文章首先让你了解慢查询的表象,让你可以通过一些工具识别出慢查询语句;
然后告诉你SQL优化的一些常用套路技巧,掌握这些套路技巧至少可以解决80%的SQL优化问题;
最后通过一个示例从分析开始一步一步完成慢查询语句的优化,其中查看执行计划是优化过程中最终要的操作,大家一定要掌握。
本文分享自微信公众号 - JAVA日知录(javadaily)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。