背景

最近慢sql 性能優化 發現一個調用頻率高的sql 使用 in 子查詢，導致外層全表掃描的問題？
為什么會產生這樣的問題？特別強調在優化的使用發現 使用in 和優化后的效果差距 300倍，可見全表掃描的效果可多厲害。 mysql 版本 5.6

參考

搜集了一下資料發現 https://www.cnblogs.com/wy123/archive/2017/06/28/7092194.html 這篇 文章特別像我們的場景，子查詢中 查詢一個條件，然后非常慢使用不上索引

實踐

創建表

create table test_table2 (id int auto_incrementprimary key,pay_id int null,pay_time datetime null,other_col varchar(100) null );create index test_table2_pay_id_indexon test_table2 (pay_id);

執行計劃

explain extended select * from test_table2 where pay_id in(select pay_id from test_table2where pay_id > 800group by pay_idhaving count(pay_id) > 2);

從執行計劃可以看出 先執行子查詢(SUBQUERY), 然后掃描了全表的數據。

[{"id": 1,"select_type": "PRIMARY","table": "test_table2","partitions": null,"type": "ALL","possible_keys": null,"key": null,"key_len": null,"ref": null,"rows": 1010,"filtered": 100,"Extra": "Using where"},{"id": 2,"select_type": "SUBQUERY","table": "test_table2","partitions": null,"type": "range","possible_keys": "test_table2_pay_id_index","key": "test_table2_pay_id_index","key_len": "5","ref": null,"rows": 200,"filtered": 100,"Extra": "Using where; Using index"} ]

即使強制指定索引也沒有用

explain extended select * from test_table2 force index(test_table2_pay_id_index) where pay_id in(select pay_id from test_table2where pay_id > 800group by pay_idhaving count(pay_id) > 2);

為什么？

如果直接使用這種查詢 (pay_id) in 常量

效率杠杠的，使用了索引 pay_id

explain select * from test_table2 where pay_id in(800,900)

為什么沒有命中索引？

子查詢的結果是未知的，不能作為外層的索引判斷 。【高版本mysql優化器應該會優化成連接查詢】
以上就是利用，在SQL 查詢語言執行流程中，優化器執行計劃生成已經索引選擇階段，子查詢的結果無法提供任何的判斷依據，因此不能作為外層判斷索引的依據，由此導致外層直接全表掃描了。具體可以參考一下 Mysql的查詢流程。
MySql查詢語句執行流程

如何改進

接改為連接查詢非常快

explain extended select * from test_table2 as t1inner join (select pay_id from test_table2where pay_id > 800group by pay_idhaving count(pay_id) > 2)as tmp on tmp.pay_id =t1.pay_id;

總結

對于子查詢慎用 in，常量情況下可以使用 in 涉及多表操作 in 最好使用 連接查詢，性能差異可能幾百倍。

總結

以上是生活随笔為你收集整理的mysql in 子查询无法使用索引全表扫描 慎用in的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。