語句一：select count(*) from A where A.a not in (select a from B)

語句二：select count(*) from A left join B on A.a = B.a where B.a is null

語句三：select count(*) from A where not exists (select a from B where A.a = B.a)

知道以上三條語句的實(shí)際效果是相同的已經(jīng)很久了，但是一直沒有深究其間的效率對比。一直感覺上語句二是最快的。 今天工作上因?yàn)橐獙σ粋€數(shù)千萬行數(shù)據(jù)的庫進(jìn)行數(shù)據(jù)清除，需要刪掉兩千多萬行數(shù)據(jù)。大量的用到了以上三條語句所要實(shí)現(xiàn)的功能。本來用的是語句一，但是結(jié)果是執(zhí)行速度1個小時32分，日志文件占用21GB。時間上雖然可以接受，但是對硬盤空間的占用確是個問題。因此將所有的語句一都換成語句二。本以為會更快。沒想到執(zhí)行40多分鐘后，第一批50000行都沒有刪掉，反而讓SQL SERVER崩潰掉了，結(jié)果令人詫異。試了試單獨(dú)執(zhí)行這條語句，查詢近一千萬行的表，語句一用了4秒，語句二卻用了18秒，差距很大。語句三的效率與語句一接近。

第二種寫法是大忌，應(yīng)該盡量避免。第一種和第三種寫法本質(zhì)上幾乎一樣。

假設(shè)buffer pool足夠大，寫法二相對于寫法一來說存在以下幾點(diǎn)不足： (1)left join本身更耗資源(需要更多資源來處理產(chǎn)生的中間結(jié)果集) (2)left join的中間結(jié)果集的規(guī)模不會比表A小 (3)寫法二還需要對left join產(chǎn)生的中間結(jié)果做is null的條件篩選，而寫法一則在兩個集合join的同時完成了篩選，這部分開銷是額外的

這三點(diǎn)綜合起來，在處理海量數(shù)據(jù)時就會產(chǎn)生比較明顯的區(qū)別(主要是內(nèi)存和CPU上的開銷)。我懷疑樓主在測試時buffer pool可能已經(jīng)處于飽和狀態(tài)，這樣的話，寫法二的那些額外開銷不得不借助磁盤上的虛擬內(nèi)存，在SQL Server做換頁時，由于涉及到較慢的I/O操作因此這種差距會更加明顯。

關(guān)于日志文件過大，這也是正常的，因?yàn)閯h除的記錄多嘛。可以根據(jù)數(shù)據(jù)庫的用途考慮將恢復(fù)模型設(shè)為simple，或者在刪除結(jié)束后將日志truncate掉并把文件shrink下來。

因?yàn)橐郧霸?jīng)作過一個對這個庫進(jìn)行無條件刪除的腳本，就是要刪除數(shù)據(jù)量較大的表中的所有數(shù)據(jù)，但是因?yàn)榭蛻粢?#xff0c;不能使用truncate table，怕破壞已有的庫結(jié)構(gòu)。所以只能用delete刪，當(dāng)時也遇到了日志文件過大的問題，當(dāng)時采用的方法是分批刪除，在SQL2K中用set rowcount @chunk，在SQL2K5中用delete top @chunk。這樣的操作不僅使刪除時間大大減少，而且讓日志量大大減少，只增長了1G左右。 但是這次清除數(shù)據(jù)的工作需要加上條件，就是delete A from A where ....后面有條件的。再次使用分批刪除的方法，卻已經(jīng)沒效果了。 不知您知不知道這是為什么。

mysql not in 和 left join 效率問題記錄

首先說明該條sql的功能是查詢集合a不在集合b的數(shù)據(jù)。 not in的寫法

select add_tb.RUID

from (select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime>'2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) add_tb

where add_tb.RUID

not in (select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime

)

返回444行記錄用時 0.07sec explain 結(jié)果

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows |

Extra |

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 452 |

Using where |

| 3 | DEPENDENT SUBQUERY | UserMsg | index_subquery | RUID,SubjectID,CreateTime | RUID | 96 | func | 2 |

Using index; Using where |

| 2 | DERIVED | UserMsg | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1857 |

Using where; Using temporary |

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

分析:該條查詢速度快原因?yàn)閕d=2的sql查詢出來的結(jié)果比較少，所以id=1sql所以運(yùn)行速度比較快，id=2的使用了臨時表，不知道這個時候是否使用索引？ 其中一種left join

select a.ruid,b.ruid

from(select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) a left join (

select distinct RUID

from UserMsg

where SubjectID =12 and CreateTime< '2009-8-14 15:30:00'

) b on a.ruid = b.ruid

where b.ruid is null

返回444行記錄用時 0.39sec

explain 結(jié)果

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 452 |

|

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1112 | Using where; Not exists

|

| 3 | DERIVED | UserMsg | ref | SubjectID,CreateTime | SubjectID | 5 | | 6667 | Using where; Using

temporary |

| 2 | DERIVED | UserMsg | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1838 | Using where; Using

temporary |

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

分析:使用了兩個臨時表，并且兩個臨時表做了笛卡爾積，導(dǎo)致不能使用索引并且數(shù)據(jù)量很大

另外一種left join

復(fù)制代碼 代碼如下:

select distinct a.RUID

from UserMsg a

left join UserMsg b

on a.ruid = b.ruid

and b.subjectID =12 and b.createTime < '2009-8-14 15:30:00'

where a.subjectID =12

and a.createTime >= '2009-8-14 15:30:00'

and a.createtime <='2009-8-17 16:00:00'

and b.ruid is null;

返回444行記錄用時 0.07sec

explain 結(jié)果

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

| 1 | SIMPLE | a | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1839 | Using where;

Using temporary |

| 1 | SIMPLE | b | ref | RUID,SubjectID,CreateTime | RUID | 96 | dream.a.RUID | 2 | Using where;

Not exists; Distinct |

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

分析：兩次查詢都是用上了索引，并且查詢時同時進(jìn)行的，所以查詢效率應(yīng)該很高

使用not exists的sql

復(fù)制代碼 代碼如下:

select distinct a.ruid

from UserMsg a

where a.subjectID =12

and a.createTime >= '2009-8-14 15:30:00'

and a.createTime <='2009-8-17 16:00:00'

and not exists (

select distinct RUID

from UserMsg

where subjectID =12 and createTime < '2009-8-14 15:30:00'

and ruid=a.ruid

)

返回444行記錄用時 0.08sec

explain 結(jié)果

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

| 1 | PRIMARY | a | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1839 | Using

where; Using temporary |

| 2 | DEPENDENT SUBQUERY | UserMsg | ref | RUID,SubjectID,CreateTime | RUID | 96 | dream.a.RUID | 2 | Using

where |

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

分析：同上基本上是一樣的，只是分解了2個查詢順序執(zhí)行，查詢效率低于第3個

為了驗(yàn)證數(shù)據(jù)查詢效率，將上述查詢中的subjectID =12的限制條件去掉，結(jié)果統(tǒng)計(jì)查詢時間如下

0.20s

21.31s

0.25s

0.43s

laserhe幫忙分析問題總結(jié)

復(fù)制代碼 代碼如下:

select a.ruid,b.ruid

from( select distinct RUID

from UserMsg

where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) a left join UserMsg b

on a.ruid = b.ruid

and b.createTime < '2009-8-14 15:30:00'

where b.ruid is null;

執(zhí)行時間0.13s

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 |

|

| 1 | PRIMARY | b | ref | RUID,CreateTime | RUID | 96 | a.RUID | 2 | Using where; Not exists

|

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3553 | Using where; Using

temporary |

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

執(zhí)行效率類似與not in的效率

數(shù)據(jù)庫優(yōu)化的基本原則：讓笛卡爾積發(fā)生在盡可能小的集合之間，mysql在join的時候可以直接通過索引來掃描，而嵌入到子查詢里頭，查詢規(guī)

劃器就不曉得用合適的索引了。

一個SQL在數(shù)據(jù)庫里是這么優(yōu)化的：首先SQL會分析成一堆分析樹，一個樹狀數(shù)據(jù)結(jié)構(gòu)，然后在這個數(shù)據(jù)結(jié)構(gòu)里，查詢規(guī)劃器會查找有沒有合適

的索引，然后根據(jù)具體情況做一個排列組合，然后計(jì)算這個排列組合中的每一種的開銷(類似explain的輸出的計(jì)算機(jī)可讀版本)，然后比較里

面開銷最小的，選取并執(zhí)行之。那么：

explain select a.ruid,b.ruid from(select distinct RUID from UserMsg where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00' ) a left join UserMsg b on a.ruid = b.ruid and b.createTime < '2009-8-14 15:30:00'

where b.ruid is null;

和

explain select add_tb.RUID

-> from (select distinct RUID

-> from UserMsg

-> where CreateTime>'2009-8-14 15:30:00'

-> and CreateTime<='2009-8-17 16:00:00'

-> ) add_tb

-> where add_tb.RUID

-> not in (select distinct RUID

-> from UserMsg

-> where CreateTime

-> );

explain

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 | Using where

|

| 3 | DEPENDENT SUBQUERY | UserMsg | index_subquery | RUID,CreateTime | RUID | 96 | func | 2 | Using index;

Using where |

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3509 | Using where;

Using temporary |

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

開銷是完全一樣的，開銷可以從 rows 那個字段得出(基本上是rows那個字段各個行的數(shù)值的乘積，也就是笛卡爾積)

但是呢：下面這個：

explain select a.ruid,b.ruid from(select distinct RUID from UserMsg where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00' ) a left join ( select distinct RUID from UserMsg where createTime < '2009-8-14

15:30:00' ) b on a.ruid = b.ruid where b.ruid is null;

執(zhí)行時間21.31s

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 |

|

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 30308 | Using where; Not exists

|

| 3 | DERIVED | UserMsg | ALL | CreateTime | NULL | NULL | NULL | 69366 | Using where; Using temporary

|

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3510 | Using where; Using temporary

|

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

我就有些不明白

為何是四行

并且中間兩行巨大無比

按理說

查詢規(guī)劃器應(yīng)該能把這個查詢優(yōu)化得跟前面的兩個一樣的

(至少在我熟悉的pgsql數(shù)據(jù)庫里我有信心是一樣的)

但mysql里頭不是

所以我感覺查詢規(guī)劃器里頭可能還是糙了點(diǎn)

我前面說過優(yōu)化的基本原則就是，讓笛卡爾積發(fā)生在盡可能小的集合之間

那么上面最后一種寫法至少沒有違反這個原則

雖然b 表因?yàn)榉蠗l件的非常多，基本上不會用索引

但是并不應(yīng)該妨礙查詢優(yōu)化器看到外面的join on條件，從而和前面兩個SQL一樣，選取主鍵進(jìn)行join

不過我前面說過查詢規(guī)劃器的作用

理論上來講

遍歷一遍所有可能，計(jì)算一下開銷

是合理的

我感覺這里最后一種寫法沒有遍歷完整所有可能

可能的原因是子查詢的實(shí)現(xiàn)還是比較簡單？

子查詢對數(shù)據(jù)庫的確是個挑戰(zhàn)

因?yàn)榛径际沁f歸的東西

所以在這個環(huán)節(jié)有點(diǎn)毛病并不奇怪

其實(shí)你仔細(xì)想想，最后一種寫法無非是我們第一種寫法的一個變種，關(guān)鍵在表b的where 條件放在哪里

放在里面，就不會用索引去join

放在外面就會

這個本身就是排列組合的一個可能

詳細(xì)出處參考：http://www.jb51.net/article/29122.htm

總結(jié)

以上是生活随笔為你收集整理的mysql not exists 效率高_mysql not in、left join、IS NULL、NOT EXISTS 效率问题记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。