在项目开发中，同事在原本功能的基础上加入了新的业务操作代码后，导致业务操作经常超时。故对其代码进行调试跟踪后定位到，在update数据库记录时写了in子查询，完整sql如下（非原sql）：
update wms_stock set qty1 = 0 where id in (select stock_id from wms_order_line l where l.a_qty1 = 'a' and l.product_code = 'b');
查看其执行计划如下：
可以看到select_type存在DEPENDENT SUBQUERY，即子查询依赖于外查询。相当于将wms_stock表符合条件的数据（这里是全表）查出后，再拿内查询去逐条匹配是否符合l.stock_id=s.id。故 整个update语句共需扫描233253*1=233253次。
MySql 官网给出的解决方法是：
If you have a slow 'correlated' subquery with IN, you can optimize it with a join to get around the bug described by Ryan and Stephen. After the optimization the execution time is no longer O(M×N).
按照上边的思路我们将sql改为：
update wms_stock s join wms_order_line l on s.id = l.stock_id set s.qty1 = 0 where l.a_qty1 = 'a' and l.product_code = 'b';
再次查看执行计划：
修改后问题成功解决。
