故障案例 | 一次慢SQL优化分析全过程

客户发给我一个SQL，让我看看，为什么执行几分钟没有执行完。

我第一眼看到SQL的时候，也觉得很简单，优化过程比较简单，但是带来的分析过程与经验还是值得分享的。

SQL语句如下：

update ap_receive_benefits_log
  set orderstate= i_orderstate where
  requestid = i_orderid;

但是这个SQL执行时被严重阻塞了

该SQL的执行计划

疑问1

发现执行计划key走的主键，但是细看行数，会发现是全表扫描了数据。

如果没有可用索引的情况下，执行计划为什么显示走的主键，而不是空的呢？

疑问2

这个SQL里的 i_orderid 字段会不会是表中的一个字段呢，如果不是字段，是哪里来的？

分析解决步骤如下

1、确认表中的数据量约75万，这个UPDATE语句每天都需要执行很多次。
2、查看表后，发现并没有 i_orderid 字段，很是奇怪。就想这个SQL怎么来的，让开发确认一下这个SQL的来源，我来确认执行计划。如果是mysql 5.6以上版本可以直接查看UPDATE的执行计划，发现这个语句没有利用任何索引。
3、开发找了半天，确认程序没有这个语句。怎么办，好像成了‘没人认领的死尸’,开发确认不了，只能自己查了。
4、使用 pt-query-digest 分析最近