大佬们求救，慢 SQL 问题

[zzhpeng]

问题

描述：订单表，Innodb 存储引擎。排名前几个的慢 sql 语句，有些用了 count(*)，弄到 rds 数据库 cpu 满了，服务器 502.

1 、慢 sql 排名图，如下:

2 、排名第一的慢 sql 执行情况:

3 、explain 排名第一的慢 sql:

自我分析：sql 23ms 也正常呀，难道是锁的问题吗？

[zzhpeng]

@JasonLaw
sima_order.is_virtual 是不是只有 0 和 1 两种值？每个值对应的行数是多少？
回复：确实是只有 0 和 1，1 几乎很少，所以基本上是 0

[zzhpeng]

@RadishWind 看第三张图 explain

[JasonLaw]

@zzhpeng #21 所以你的索引基本没什么用，甚至会降低速度，因为对于每个符合条件的 secondary index 子节点，都会去 clustered index 搜索。

[zzhpeng]

@Airon 这条排在第一的语句很早就有了，我也觉得不像是这条的问题。排在前面的几条 count()语句是在首页的请求。

[GTim]

@zzhpeng 要不监控着，等 cpu 上去的时候执行一下 show processlist 看看是哪个超时了。

[zzhpeng]

@JasonLaw 那我有个疑问哈，为啥么我 explain 的时候是使用了索引的，而且速度是比较快的 23m 。难道是索引太多查找匹配问题，加大了数据库 cpu 资源消耗？

[Airon]

楼上也提到了，看倒数第三行，数据量级变了，应该是直接扫表了，次数还不少。索引和各种限制条件都得优化。

[realpg]

innodb 的表，最好就少 count
另外排除无关干扰把那个 orderby 干掉 虽然感觉不是这里的原因
盲猜索引差异度少，导致用索引效率更低

[JasonLaw]

@GTim #18 你理解错了，具体情况具体分析吧。

1. 你说“如果没有聚合函数，select 是在 order by -> limit 后面执行的”，此问题的例子就能够说明这种说法是错的。
2. 你说“但是有了聚合函数，select 会优于 order by -> limit 执行”，假设 SQL 是 select sum(c1) from t group by c2 order by c2，如果先执行 select sum(c1)，之后的 order by c2 怎么能够成功呢？

[mingl0280]

我建议你在服务器没有压力的时候清空排序数据一条一条测,第一条这个不像是有问题...

[zzhpeng]

@GTim 这个难，那么多超时

[MoYi123]

倒数第三句 sql 看起来更加可疑。

[leoWeek]

可能是其他慢 sql 导致服务器性能下降，sql 都阻塞住了，要看下其他慢 sql 现在的执行情况分析下

[zzhpeng]

@mingl0280 我建议你在服务器没有压力的时候清空排序数据一条一条测,第一条这个不像是有问题...
回复：这个就是当时爆发产生的情况，并不是累计的。

[JasonLaw]

@zzhpeng #26

我主要是表达“条件为 is_virtual = 0，并且大多数的 is_virtual 都是 0”的时候，idx_storeid_isvirtual 其实是没有什么用处的。

你那条语句是直接在同一个环境运行的吗？如果是的话，单独运行肯定跟同其他语句并发运行是不一样的，我不清楚具体的情况，无法给你答案。

[GTim]

@zzhpeng @zzhpeng 看 cpu 图，这个只能在高压的时候看，平时没问题说明语句都挺正常，当然如果这个时候有不正常的，那就太不正常了。找到那条语句优化下

[cnoder]

你这个管理 sql 的界面叫啥

[qwerthhusn]

都 count 了，何不把 order by 去掉？？

[zzhpeng]

@cnoder 阿里的 rds

[wps353]

本质是 in +order by 出问题了。