在項(xiàng)目開發(fā)中，同事在原本功能的基礎(chǔ)上加入了新的業(yè)務(wù)操作代碼后，導(dǎo)致業(yè)務(wù)操作經(jīng)常超時(shí)。故對(duì)其代碼進(jìn)行調(diào)試跟蹤后定位到，在update數(shù)據(jù)庫記錄時(shí)寫了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');

查看其執(zhí)行計(jì)劃如下：

可以看到select_type存在DEPENDENT SUBQUERY，即子查詢依賴于外查詢。相當(dāng)于將wms_stock表符合條件的數(shù)據(jù)（這里是全表）查出后，再拿內(nèi)查詢?nèi)ブ饤l匹配是否符合l.stock_id=s.id。故 整個(gè)update語句共需掃描233253*1=233253次。

MySql 官網(wǎng)給出的解決方法是：

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';

再次查看執(zhí)行計(jì)劃：

修改后問題成功解決。