對于in子查詢性能暖璧，眾說紛紜案怯。有的人說 in 子查詢性能很差，不能使用索引澎办。而有人說 in 子查詢能用索引嘲碱，而且性能很好。
今天我就給大家做個實驗局蚀，來驗證這些說法麦锯。
首先，我使用MySQL_5.1.73做測試琅绅。
有一個test庫扶欣，庫中有兩張表：
data_school：全國各地的學(xué)校
t1 ：三個學(xué)校id
我們來演示兩種in子查詢：
第一種：直接輸入具體的值：
select * from data_school where id in (1101010002,1101010012,1101010014);
select * from data_school where id in ( select id from t1 );
大家可以看到，兩者的性能都不在一個數(shù)量級上千扶，非常的夸張料祠。
我們再用explain去分析它們使用索引的情況。
對于explain與 profiling如果還不了解的話县貌，可以看我上一篇文章。
對于第一條語句凑懂，大家可以看到煤痕，是一個simple 查詢，沒有子查詢接谨，而且使用了primary key索引摆碉。
我們再看看第二條語句：
首先是對data_school做了全盤掃描，這個是比較失敗的查詢脓豪。
這條查詢和我們的思維不太一樣巷帝，我們一般會認為
先執(zhí)行 select id from t1,
再執(zhí)行select * from data_school。
而實際的情況是扫夜，select * from data_school做全盤掃描楞泼，然后再一條條的去匹配表t1驰徊。
現(xiàn)在大家明白了吧，遇到這種問題堕阔，不能按我們的直覺去判斷棍厂，要通過具體的實驗分析獲取結(jié)果。
最后注意一點
MySQL升級到5.6的時候超陆，這個問題已經(jīng)被修復(fù)牺弹，我再給大家看一個在MySQL5.6中的實驗。直接上圖：
大家可以看到?jīng)]啥大的差距时呀。
看下圖张漂，大家注意到?jīng)]有，相比5.1.37谨娜，它們查詢的順序發(fā)生了變化航攒，先查t1，使用primary key瞧预。
然后再查data_school,也使用了primary key屎债。兩條查詢都是simple類型。
MySQL5.6修復(fù)了這個問題垢油，這大概就是為什么有人說性能差盆驹，有人說性能好的原因吧！
建議大家使用較高版本的MySQL滩愁。
