解決MySQL中IN子查詢會導(dǎo)致無法使用索引問題
今天看到一篇關(guān)于MySQL的IN子查詢優(yōu)化的案例,
一開始感覺有點半信半疑(如果是換做在SQL Server中,這種情況是絕對不可能的,后面會做一個簡單的測試。)
隨后動手按照他說的做了一個表來測試驗證,發(fā)現(xiàn)MySQL的IN子查詢做的不好,確實會導(dǎo)致無法使用索引的情況(IN子查詢無法使用所以,場景是MySQL,截止的版本是5.7.18)
MySQL的測試環(huán)境
測試表如下
create table test_table2 ( id int auto_increment primary key, pay_id int, pay_time datetime, other_col varchar(100) )
建一個存儲過程插入測試數(shù)據(jù),測試數(shù)據(jù)的特點是pay_id可重復(fù),這里在存儲過程處理成,循環(huán)插入300W條數(shù)據(jù)的過程中,每隔100條數(shù)據(jù)插入一條重復(fù)的pay_id,時間字段在一定范圍內(nèi)隨機
CREATE DEFINER=`root`@`%` PROCEDURE `test_insert`(IN `loopcount` INT) LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT '' BEGIN declare cnt int; set cnt = 0; while cnt< loopcount do insert into test_table2 (pay_id,pay_time,other_col) values (cnt,date_add(now(), interval floor(300*rand()) day),uuid()); if (cnt mod 100 = 0) then insert into test_table2 (pay_id,pay_time,other_col) values (cnt,date_add(now(), interval floor(300*rand()) day),uuid()); end if; set cnt = cnt + 1; end while; END
執(zhí)行 call test_insert(3000000); 插入303000行數(shù)據(jù)
兩種子查詢的寫法
查詢大概的意思是查詢某個時間段之內(nèi)的業(yè)務(wù)Id大于1的數(shù)據(jù),于是就出現(xiàn)兩種寫法。
第一種寫法如下:IN子查詢中是某段時間內(nèi)業(yè)務(wù)統(tǒng)計大于1的業(yè)務(wù)Id,外層按照IN子查詢的結(jié)果進(jìn)行查詢,業(yè)務(wù)Id的列pay_id上有索引,邏輯也比較簡單,這種寫法,在數(shù)據(jù)量大的時候確實效率比較低,用不到索引
select * from test_table2 force index(idx_pay_id) where pay_id in ( select pay_id from test_table2 where pay_time>="2016-06-01 00:00:00" AND pay_time<="2017-07-03 12:59:59" group by pay_id having count(pay_id) > 1 );
執(zhí)行結(jié)果:2.23秒
第二種寫法,與子查詢進(jìn)行join關(guān)聯(lián),這種寫法相當(dāng)于上面的IN子查詢寫法,下面測試發(fā)現(xiàn),效率確實有不少的提高
select tpp1.* from test_table2 tpp1, ( select pay_id from test_table2 WHERE pay_time>="2016-07-01 00:00:00" AND pay_time<="2017-07-03 12:59:59" group by pay_id having count(pay_id) > 1 ) tpp2 where tpp1.pay_id=tpp2.pay_id
執(zhí)行結(jié)果:0.48秒
In子查詢的執(zhí)行計劃,發(fā)現(xiàn)外層查詢是一個全表掃描的方式,沒有用到pay_id上的索引
join自查的執(zhí)行計劃,外層(tpp1別名的查詢)是用到pay_id上的索引的。
后面想對第一種查詢方式使用強制索引,雖然是不報錯的,但是發(fā)現(xiàn)根本沒用
如果子查詢是直接的值,則是可以正常使用索引的。
可見MySQL對IN子查詢的支持,做的確實不怎么樣。
另外:加一個使用臨時表的情況,雖然比不少join方式查詢的,但是也比直接使用IN子查詢效率要高,這種情況下,也是可以使用到索引的,不過這種簡單的情況,是沒有必要使用臨時表的。
下面是類似案例在sqlserver 2014中的測試,幾萬完全一樣的測試表結(jié)構(gòu)和數(shù)量,可見這種情況下,兩種寫法,在SQL Server中可以認(rèn)為是完全一樣的(執(zhí)行計劃+效率),這一點SQL Server要比MySQL強不少
下面是sqlserver中的測試環(huán)境腳本。
create table test_table2 ( id int identity(1,1) primary key, pay_id int, pay_time datetime, other_col varchar(100) ) begin tran declare @i int = 0 while @i<300000 begin insert into test_table2 values (@i,getdate()-rand()*300,newid()); if(@i%1000=0) begin insert into test_table2 values (@i,getdate()-rand()*300,newid()); end set @i = @i + 1 end COMMIT GO create index idx_pay_id on test_table2(pay_id); create index idx_time on test_table2(pay_time); GO select * from test_table2 where pay_id in ( select pay_id from test_table2 where pay_time>='2017-01-21 00:00:00' AND pay_time<='2017-07-03 12:59:59' group by pay_id having count(pay_id) > 1 ); select tpp1.* from test_table2 tpp1, ( select pay_id from test_table2 WHERE pay_time>='2017-01-21 00:00:00' AND pay_time<='2017-07-30 12:59:59' group by pay_id having count(pay_id) > 1 ) tpp2 where tpp1.pay_id=tpp2.pay_id
總結(jié):在MySQL數(shù)據(jù)中,截止5.7.18版本,對IN子查詢,仍要慎用
相關(guān)文章
MySQL數(shù)據(jù)庫和Redis緩存一致性的更新策略
本文主要介紹了MySQL數(shù)據(jù)庫和Redis緩存一致性的更新策略問題,文中有詳細(xì)的代碼示例,有需要的朋友可以參考一下2023-04-04Mysql動態(tài)更新數(shù)據(jù)庫腳本的示例講解
今天小編就為大家分享一篇關(guān)于Mysql動態(tài)更新數(shù)據(jù)庫腳本的示例講解,小編覺得內(nèi)容挺不錯的,現(xiàn)在分享給大家,具有很好的參考價值,需要的朋友一起跟隨小編來看看吧2018-12-12MySQL進(jìn)行大數(shù)據(jù)量分頁的優(yōu)化技巧分享
mysql大數(shù)據(jù)量分頁情況下性能會很差,所以本文就來講一講mysql大數(shù)據(jù)量下偏移量很大,性能很差的問題,并附上解決方式,希望對大家有所幫助2024-01-01MySQL刪除數(shù)據(jù),表文件大小依然沒變的原因
這篇文章主要介紹了MySQL刪除數(shù)據(jù),表文件大小依然沒變的原因,幫助大家更好的理解MySQL中的數(shù)據(jù)表,感興趣的朋友可以了解下2020-10-10