面试官：给你一段有问题的SQL，如何优化？

我在面试的时候很喜欢问候选人这样一个问题：“你在项目中遇到过慢查询问题吗？你是怎么做SQL优化的？”

很多时候，候选人会直接跟我说他们在编写SQL时会遵循的一些常用技巧，比如：

• 合理使用索引

• 使用UNION ALL替代UNION

• 不要使用select * 写法

• JOIN字段建议建立索引

• 避免复杂SQL语句

这里不能说完全错误，因为这些技巧确实可以提高SQL运行效率；但是也不能说完全正确，毕竟我是想问他具体怎么是做SQL优化的。

接下来我问他，我这里有一段复杂的SQL，你可以动手帮我优化一下吗？到这一步的时候就有很多候选人做不好打了退堂鼓。他们有很扎实的理论知识，但是动手能力却差点火候。

今天这篇文章就从实战的角度出发，带大家走一遍SQL优化的真实流程。

找出有问题的SQL？

在实际开发中要判断一段SQL有没有问题可以从两方面来判断：

1、系统层面

• CPU消耗严重

• IO等待严重

• 页面响应时间过长

• 应用的日志出现超时等错误

2、SQL语句层面

• 冗长

• 执行时间过长

• 从全表扫描获取数据

• 执行计划中的rows、cost很大

冗长的SQL都好理解，一段SQL太长阅读性肯定会差，出现问题的频率肯定会更高。更进一步判断SQL问题就必须得从执行计划入手，如下所示：

 

执行计划告诉我们本次查询走了全表扫描Type=ALL，rows很大(9950400)基本可以判断这是一段"有味道"的SQL。

查看SQL执行计划？

找到了有问题的SQL就要确定优化方案，那究竟从何处下手呢？这里必须要通过执行计划来观察。

执行计划会告诉你哪些地方效率低，哪里可以需要优化。我们以MYSQL为例，看看执行计划是什么。（每个数据库的执行计划都不一样，需要自行了解）

explain select * from