一次SQL优化过程

场景

第一步：发现问题

一个页面列表接口，耗时 6.98s。

我认为一个前端接口耗时超过1s就是耍流氓。

第二步：定位问题

使用arthas神器打印接口耗时。arthas的部署及使用方法可以参见：
arthas独家心得
如果不会使用arthas的开发，我不认为他是一个高级开发。

可见问题在 mapper那里出问题了，我一直猜想是拉列表后因为循环拉取详情导致的慢，看来我的经验不对，所以碰到问题，先从本质核实问题的原因，是程序员解决问题的第一步，而不是瞎猜，惊慌失措。

第三步：找出问题，打印SQL。

因为有一个相同的业务没有发生这个耗时长的问题，我就自己再去打印了2个业务的不同点。

SELECT
	phone_order.* 
FROM
	phone_order
	LEFT JOIN phone_order_extend AS extend ON phone_order.id = extend.order_id 
WHERE
	1 = 1 
	AND phone_order.category = 5
	AND extend.create_group_name =  '台南區' 
ORDER BY
	phone_order.gmt_create DESC 
	LIMIT 20;


EXPLAIN SELECT
	phone_order.*,phone_order_extend.*
FROM
	phone_order
	LEFT JOIN phone_order_extend AS extend ON phone_order.id = extend.order_id 
WHERE
	1 = 1 
	AND phone_order.category = 5 
ORDER BY
	phone_order.gmt_create DESC 
	LIMIT 20;

第四步：分析问题

有经验的老司机一看就知道区别：

extend表 order_id字段没有索引。
那个没出问题的业务，是因为extend表先过滤了一个字段，把数据减少了才没出问题。

我们从 type 看出没出问题的业务SQL走了ALL，然后走了 order表的Id索引
出问题的SQL，extend走了ALL，然后order表也走了 ALL。

赶紧优化一波，先把extend表加入 order_id的索引。

优化后，速度从 6秒降低到 0.3s. 这让我没有一点成就感。

我就又看了看explain。一般我会比较关注 type, ref,key_len,Extra。所以我又多看了一眼。

发现Extra 怎么还在用自己的优化算法。一般是order by 问题
赶紧给排序 gmt_create 加索引。

我看到第一个order表也进入了索引了，过滤的行数也只有 从8、9千降低至19条。我们再看看效果，耗时降低至 250ms.

这么看也没有什么优化空间了。没点意思，我以为会出现一些知识盲点，强化自己一波优化能力。就当做知识复习了。