SQL語句優化 SQL語句優化
SQL語句優化
怎麼加快查詢速度，優化查詢效率，主要原則就是應儘量避免全表掃描，應該考慮在where及order by 涉及的列上建立索引。
建立索引不是建的越多越好，原則是：
第一：一個表的索引不是越多越好，也沒有一個具體的數字，根據以往的經驗，一個表的索引最多不能超過6個，因為索引越多，對update和insert操作也會有效能的影響，涉及到索引的新建和重建操作。
第二：建立索引的方法論為：
- 多數查詢經常使用的列；
- 很少進行修改操作的列；
- 索引需要建立在資料差異化大的列上
利用以上的基礎我們討論一下如何優化sql.
1、sql語句模型結構優化指導
a. ORDER BY + LIMIT組合的索引優化
如果一個SQL語句形如：SELECT [column1],[column2],…. FROM [TABLE] ORDER BY [sort] LIMIT [offset],[LIMIT];
這個SQL語句優化比較簡單，在[sort]這個欄位上建立索引即可。
b. WHERE + ORDER BY + LIMIT組合的索引優化
如果一個SQL語句形如：SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] = [VALUE] ORDER BY [sort] LIMIT [offset],[LIMIT];
這個語句，如果你仍然採用第一個例子中建立索引的方法，雖然可以用到索引，但是效率不高。更高效的方法是建立一個聯合索引(columnX,sort)
c. WHERE+ORDER BY多個欄位+LIMIT
如果一個SQL語句形如：SELECT * FROM [table] WHERE uid=1 ORDER x,y LIMIT 0,10;
對於這個語句，大家可能是加一個這樣的索引:(x,y,uid)。但實際上更好的效果是(uid,x,y)。這是由MySQL處理排序的機制造成的。
2、複合索引(形如(x,y,uid)索引的索引)
先看這樣一條語句這樣的：select* from users where area =’beijing’ and age=22;
如果我們是在area和age上分別建立索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果area，age兩列上建立複合索引的話將帶來更高的效率。
在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。
例如我們建立了一個這樣的索引（area,age,salary），那麼其實相當於建立了（area,age,salary）,(area,age),(area)三個索引，這樣稱為最佳左字首特性。
3、like語句優化
SELECT id FROM A WHERE name like '%abc%'
由於abc前面用了“%”，因此該查詢必然走全表查詢，除非必要，否則不要在關鍵詞前加%，優化成如下
SELECT id FROM A WHERE name like 'abc%'
4、where子句使用 ！= 或 <> 操作符優化
在where子句中使用 ！= 或 <>操作符，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE ID != 5 優化成：SELECT id FROM A WHERE ID>5 OR ID<5
5、where子句中使用 IS NULL 或 IS NOT NULL 的優化
在where子句中使用 IS NULL 或 IS NOT NULL 判斷，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE num IS NULL 優化成num上設定預設值0，確保表中num沒有null值，然後SQL為：SELECT id FROM A WHERE num=0
6、where子句使用or的優化
很多時候使用union all 或 nuin(必要的時候)的方式替換“or”會得到更好的效果。where子句中使用了or,索引將被放棄使用。
如SQL:SELECT id FROM A WHERE num =10 or num = 20 優化成：SELECT id FROM A WHERE num = 10 union all SELECT id FROM A WHERE num=20
7、where子句使用IN 或 NOT IN的優化
in和not in 也要慎用，否則也會導致全表掃描。
方案一：between替換in
如SQL:SELECT id FROM A WHERE num in(1,2,3) 優化成：SELECT id FROM A WHERE num between 1 and 3
方案二：exist替換in
如SQL:SELECT id FROM A WHERE num in(select num from b ) 優化成：SELECT num FROM A WHERE num exists(select 1 from B where B.num = A.num)
方案三：left join替換in
如SQL:SELECT id FROM A WHERE num in(select num from B) 優化成：SELECT id FROM A LEFT JOIN B ON A.num = B.num
8、where子句中對欄位進行表示式操作的優化
不要在where子句中的“=”左邊進行函式、算數運算或其他表示式運算，否則系統將可能無法正確使用索引。
如SQL:SELECT id FROM A WHERE num/2 = 100 優化成：SELECT id FROM A WHERE num = 100*2
如SQL:SELECT id FROM A WHERE substring(name,1,3) = 'abc' 優化成：SELECT id FROM A WHERE LIKE 'abc%'
如SQL:SELECT id FROM A WHERE datediff(day,createdate,'2016-11-30')=0 優化成：SELECT id FROM A WHERE createdate>='2016-11-30' and createdate<'2016-12-1'
如SQL:SELECT id FROM A WHERE year(addate) <2016 優化成：SELECT id FROM A where addate<'2016-01-01'
9、任何地方都不要用 select * from table ，用具體的欄位列表替換"*"，不要返回用不到的欄位
10、使用“臨時表”暫存中間結果
採用臨時表暫存中間結果好處：
（1）避免程式中多次掃描主表，減少程式執行“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了併發效能。
（2）儘量使用表變數來代替臨時表。如果表變數包含大量資料，請注意索引非常有限（只有主鍵索引）。
（3）避免頻繁建立和刪除臨時表，以減少系統資源的浪費。
（4）儘量避免向客戶端返回大資料量，若資料量過大，應考慮相應需求是否合理。
11、limit分頁優化
當偏移量特別時，limit效率會非常低
SELECT id FROM A LIMIT 1000,10 很快
SELECT id FROM A LIMIT 90000,10 很慢
優化方法：
方法一：select id from A order by id limit 90000,10; 很快，0.04秒就OK。 因為用了id主鍵做索引當然快
方法二：select id,title from A where id>=(select id from collect order by id limit 90000,1) limit 10;
方法三：select id from A order by id between 10000000 and 10000010;
12、批量插入優化
INSERT into person(name,age) values('A',14)
INSERT into person(name,age) values('B',14)
INSERT into person(name,age) values('C',14)
可優化為：
INSERT into person(name,age) values('A',14),('B',14),('C',14),
13、利用limit 1 、top 1 取得一行
有時要查詢一張表時，你知道只需要看一條記錄，你可能去查詢一條特殊的記錄。可以使用limit 1 或者 top 1 來終止資料庫索引繼續掃描整個表或索引。
如SQL：SELECT id FROM A LIKE 'abc%' 優化為：SELECT id FROM A LIKE 'abc%' limit 1
14、儘量不要使用 BY RAND()命令
BY RAND()是隨機顯示結果，這個函式可能會為表中每一個獨立的行執行BY RAND()命令，這個會消耗處理器的處理能力。
如SQL：SELECT * FROM A order by rand() limit 10 優化為：SELECT * FROM A WHERE id >= ((SELECT MAX(id) FROM A)-(SELECT MIN(id) FROM A)) * RAND() + (SELECT MIN(id) FROM A) LIMIT 10
15、排序的索引問題
Mysql查詢只是用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫預設排序可以符合要求情況下不要使用排序操作；
儘量不要包含多個列的排序，如果需要最好給這些列建立複合索引。
16、儘量用 union add 替換 union
union和union all的差異主要是前者需要將兩個（或者多個）結果集合並後再進行唯一性過濾操作，這就會涉及到排序，增加大量的cpu運算，加大資源消耗及延遲。所以當我們可以確認不可能出現重複結果集或者不在乎重複結果集的時候，儘量使用union all而不是union
17、避免型別轉換
這裡所說的“型別轉換”是指where子句中出現column欄位的型別和傳入的引數型別不一致的時候發生的型別轉換。人為的上通過轉換函式進行轉換，直接導致mysql無法使用索引。如果非要轉型，應該在傳入引數上進行轉換。
例如utime 是datetime型別，傳入的引數是“2016-07-23”，在比較大小時通常是 date（utime）>"2016-07-23",可以優化為utime>"2016-07-23 00：00：00"
18、儘可能使用更小的欄位
MySQL從磁碟讀取資料後是儲存到記憶體中的，然後使用cpu週期和磁碟I/O讀取它，這意味著越小的資料型別佔用的空間越小，從磁碟讀或打包到記憶體的效率都更好，但也不要太過執著減小資料型別，要是以後應用程式發生什麼變化就沒有空間了。
修改表將需要重構，間接地可能引起程式碼的改變，這是很頭疼的問題，因此需要找到一個平衡點。
19、Inner join 和 left join、right join、子查詢
第一：inner join內連線也叫等值連線是，left/rightjoin是外連線。
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;
SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;
經過來之多方面的證實inner join效能比較快，因為inner join是等值連線，或許返回的行數比較少。但是我們要記得有些語句隱形的用到了等值連線，如：
SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;
推薦：能用inner join連線儘量使用inner join連線
第二：子查詢的效能又比外連線效能慢，儘量用外連線來替換子查詢。
Select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);
A表的資料為十萬級表，B表為百萬級表，在本機執行差不多用2秒左右，我們可以通過explain可以檢視到子查詢是一個相關子查詢(DEPENDENCE SUBQUERY);Mysql是先對外表A執行全表查詢，然後根據uuid逐次執行子查詢，如果外層表是一個很大的表，我們可以想象查詢效能會表現比這個更加糟糕。
一種簡單的優化就是用innerjoin的方法來代替子查詢，查詢語句改為：
Select* from A inner join B ON A.uuid=B.uuid using(uuid) where b.uuid>=3000; 這個語句執行測試不到一秒；
第三：使用JOIN時候，應該用小的結果驅動打的結果（left join 左邊表結果儘量小，如果有條件應該放到左邊先處理，right join同理反向），同時儘量把牽涉到多表聯合的查詢拆分多個query (多個表查詢效率低，容易鎖表和阻塞)。如：
Select * from A left join B A.id=B.ref_id where A.id>10;可以優化為：select * from (select * from A wehre id >10) T1 left join B on T1.id=B.ref_id;
20、exist 代替 in
SELECT * from A WHERE idin (SELECT id from B)
SELECT * from A WHERE id EXISTS(SELECT 1 from A.id= B.id)
in 是在記憶體中遍歷比較
exist 需要查詢資料庫，所以當B的資料量比較大時，exists效率優於in.
in()只執行一次，把B表中的所有id欄位快取起來，之後檢查A表的id是否與B表中的id相等，如果id相等則將A表的記錄加入到結果集中，直到遍歷完A表的所有記錄。
In 操作的流程原理如同一下程式碼
List resultSet={};
Array A=(select * from A);
Array B=(select id from B);
for(int i=0;i<A.length;i++) {
for(int j=0;j<B.length;j++) {
if(A[i].id==B[j].id) {
resultSet.add(A[i]);
break;
}
}
}
return resultSet;
可以看出，當B表資料較大時不適合使用in()，因為它會B表資料全部遍歷一次
如：A表有10000條記錄，B表有1000000條記錄，那麼最多有可能遍歷10000*1000000次，效率很差。
再如：A表有10000條記錄，B表有100條記錄，那麼最多有可能遍歷10000*100次，遍歷次數大大減少，效率大大提升。
結論：in()適合B表比A表資料小的情況
exist()會執行A.length()次，執行過程程式碼如下
List resultSet={};
Array A=(select * from A);
for(int i=0;i<A.length;i++) {
if(exists(A[i].id) { //執行select 1 from B where B.id=A.id是否有記錄返回
resultSet.add(A[i]);
}
}
return resultSet;
當B表比A表資料大時適合使用exists()，因為它沒有那麼多遍歷操作，只需要再執行一次查詢就行。
如：A表有10000條記錄，B表有1000000條記錄，那麼exists()會執行10000次去判斷A表中的id是否與B表中的id相等。
如：A表有10000條記錄，B表有100000000條記錄，那麼exists()還是執行10000次，因為它只執行A.length次，可見B表資料越多，越適合exists()發揮效果。
再如：A表有10000條記錄，B表有100條記錄，那麼exists()還是執行10000次，還不如使用in()遍歷10000*100次，因為in()是在記憶體裡遍歷比較，而exists()需要查詢資料庫，
我們都知道查詢資料庫所消耗的效能更高，而記憶體比較很快。
結論：exists()適合B表比A表資料大的情況
當A表資料與B表資料一樣大時，in與exists效率差不多，可任選一個使用。
怎麼加快查詢速度，優化查詢效率，主要原則就是應儘量避免全表掃描，應該考慮在where及order by 涉及的列上建立索引。
建立索引不是建的越多越好，原則是：
第一：一個表的索引不是越多越好，也沒有一個具體的數字，根據以往的經驗，一個表的索引最多不能超過6個，因為索引越多，對update和insert操作也會有效能的影響，涉及到索引的新建和重建操作。
第二：建立索引的方法論為：
- 多數查詢經常使用的列；
- 很少進行修改操作的列；
- 索引需要建立在資料差異化大的列上
利用以上的基礎我們討論一下如何優化sql.
1、sql語句模型結構優化指導
a. ORDER BY + LIMIT組合的索引優化
如果一個SQL語句形如：SELECT [column1],[column2],…. FROM [TABLE] ORDER BY [sort] LIMIT [offset],[LIMIT];
這個SQL語句優化比較簡單，在[sort]這個欄位上建立索引即可。
b. WHERE + ORDER BY + LIMIT組合的索引優化
如果一個SQL語句形如：SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] = [VALUE] ORDER BY [sort] LIMIT [offset],[LIMIT];
這個語句，如果你仍然採用第一個例子中建立索引的方法，雖然可以用到索引，但是效率不高。更高效的方法是建立一個聯合索引(columnX,sort)
c. WHERE+ORDER BY多個欄位+LIMIT
如果一個SQL語句形如：SELECT * FROM [table] WHERE uid=1 ORDER x,y LIMIT 0,10;
對於這個語句，大家可能是加一個這樣的索引:(x,y,uid)。但實際上更好的效果是(uid,x,y)。這是由MySQL處理排序的機制造成的。
2、複合索引(形如(x,y,uid)索引的索引)
先看這樣一條語句這樣的：select* from users where area =’beijing’ and age=22;
如果我們是在area和age上分別建立索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果area，age兩列上建立複合索引的話將帶來更高的效率。
在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。
例如我們建立了一個這樣的索引（area,age,salary），那麼其實相當於建立了（area,age,salary）,(area,age),(area)三個索引，這樣稱為最佳左字首特性。
3、like語句優化
SELECT id FROM A WHERE name like '%abc%'
由於abc前面用了“%”，因此該查詢必然走全表查詢，除非必要，否則不要在關鍵詞前加%，優化成如下
SELECT id FROM A WHERE name like 'abc%'
4、where子句使用 ！= 或 <> 操作符優化
在where子句中使用 ！= 或 <>操作符，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE ID != 5 優化成：SELECT id FROM A WHERE ID>5 OR ID<5
5、where子句中使用 IS NULL 或 IS NOT NULL 的優化
在where子句中使用 IS NULL 或 IS NOT NULL 判斷，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE num IS NULL 優化成num上設定預設值0，確保表中num沒有null值，然後SQL為：SELECT id FROM A WHERE num=0
6、where子句使用or的優化
很多時候使用union all 或 nuin(必要的時候)的方式替換“or”會得到更好的效果。where子句中使用了or,索引將被放棄使用。
如SQL:SELECT id FROM A WHERE num =10 or num = 20 優化成：SELECT id FROM A WHERE num = 10 union all SELECT id FROM A WHERE num=20
7、where子句使用IN 或 NOT IN的優化
in和not in 也要慎用，否則也會導致全表掃描。
方案一：between替換in
如SQL:SELECT id FROM A WHERE num in(1,2,3) 優化成：SELECT id FROM A WHERE num between 1 and 3
方案二：exist替換in
如SQL:SELECT id FROM A WHERE num in(select num from b ) 優化成：SELECT num FROM A WHERE num exists(select 1 from B where B.num = A.num)
方案三：left join替換in
如SQL:SELECT id FROM A WHERE num in(select num from B) 優化成：SELECT id FROM A LEFT JOIN B ON A.num = B.num
8、where子句中對欄位進行表示式操作的優化
不要在where子句中的“=”左邊進行函式、算數運算或其他表示式運算，否則系統將可能無法正確使用索引。
如SQL:SELECT id FROM A WHERE num/2 = 100 優化成：SELECT id FROM A WHERE num = 100*2
如SQL:SELECT id FROM A WHERE substring(name,1,3) = 'abc' 優化成：SELECT id FROM A WHERE LIKE 'abc%'
如SQL:SELECT id FROM A WHERE datediff(day,createdate,'2016-11-30')=0 優化成：SELECT id FROM A WHERE createdate>='2016-11-30' and createdate<'2016-12-1'
如SQL:SELECT id FROM A WHERE year(addate) <2016 優化成：SELECT id FROM A where addate<'2016-01-01'
9、任何地方都不要用 select * from table ，用具體的欄位列表替換"*"，不要返回用不到的欄位
10、使用“臨時表”暫存中間結果
採用臨時表暫存中間結果好處：
（1）避免程式中多次掃描主表，減少程式執行“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了併發效能。
（2）儘量使用表變數來代替臨時表。如果表變數包含大量資料，請注意索引非常有限（只有主鍵索引）。
（3）避免頻繁建立和刪除臨時表，以減少系統資源的浪費。
（4）儘量避免向客戶端返回大資料量，若資料量過大，應考慮相應需求是否合理。
11、limit分頁優化
當偏移量特別時，limit效率會非常低
SELECT id FROM A LIMIT 1000,10 很快
SELECT id FROM A LIMIT 90000,10 很慢
優化方法：
方法一：select id from A order by id limit 90000,10; 很快，0.04秒就OK。 因為用了id主鍵做索引當然快
方法二：select id,title from A where id>=(select id from collect order by id limit 90000,1) limit 10;
方法三：select id from A order by id between 10000000 and 10000010;
12、批量插入優化
INSERT into person(name,age) values('A',14)
INSERT into person(name,age) values('B',14)
INSERT into person(name,age) values('C',14)
可優化為：
INSERT into person(name,age) values('A',14),('B',14),('C',14),
13、利用limit 1 、top 1 取得一行
有時要查詢一張表時，你知道只需要看一條記錄，你可能去查詢一條特殊的記錄。可以使用limit 1 或者 top 1 來終止資料庫索引繼續掃描整個表或索引。
如SQL：SELECT id FROM A LIKE 'abc%' 優化為：SELECT id FROM A LIKE 'abc%' limit 1
14、儘量不要使用 BY RAND()命令
BY RAND()是隨機顯示結果，這個函式可能會為表中每一個獨立的行執行BY RAND()命令，這個會消耗處理器的處理能力。
如SQL：SELECT * FROM A order by rand() limit 10 優化為：SELECT * FROM A WHERE id >= ((SELECT MAX(id) FROM A)-(SELECT MIN(id) FROM A)) * RAND() + (SELECT MIN(id) FROM A) LIMIT 10
15、排序的索引問題
Mysql查詢只是用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫預設排序可以符合要求情況下不要使用排序操作；
儘量不要包含多個列的排序，如果需要最好給這些列建立複合索引。
16、儘量用 union add 替換 union
union和union all的差異主要是前者需要將兩個（或者多個）結果集合並後再進行唯一性過濾操作，這就會涉及到排序，增加大量的cpu運算，加大資源消耗及延遲。所以當我們可以確認不可能出現重複結果集或者不在乎重複結果集的時候，儘量使用union all而不是union
17、避免型別轉換
這裡所說的“型別轉換”是指where子句中出現column欄位的型別和傳入的引數型別不一致的時候發生的型別轉換。人為的上通過轉換函式進行轉換，直接導致mysql無法使用索引。如果非要轉型，應該在傳入引數上進行轉換。
例如utime 是datetime型別，傳入的引數是“2016-07-23”，在比較大小時通常是 date（utime）>"2016-07-23",可以優化為utime>"2016-07-23 00：00：00"
18、儘可能使用更小的欄位
MySQL從磁碟讀取資料後是儲存到記憶體中的，然後使用cpu週期和磁碟I/O讀取它，這意味著越小的資料型別佔用的空間越小，從磁碟讀或打包到記憶體的效率都更好，但也不要太過執著減小資料型別，要是以後應用程式發生什麼變化就沒有空間了。
修改表將需要重構，間接地可能引起程式碼的改變，這是很頭疼的問題，因此需要找到一個平衡點。
19、Inner join 和 left join、right join、子查詢
第一：inner join內連線也叫等值連線是，left/rightjoin是外連線。
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;
SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;
經過來之多方面的證實inner join效能比較快，因為inner join是等值連線，或許返回的行數比較少。但是我們要記得有些語句隱形的用到了等值連線，如：
SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;
推薦：能用inner join連線儘量使用inner join連線
第二：子查詢的效能又比外連線效能慢，儘量用外連線來替換子查詢。
Select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);
A表的資料為十萬級表，B表為百萬級表，在本機執行差不多用2秒左右，我們可以通過explain可以檢視到子查詢是一個相關子查詢(DEPENDENCE SUBQUERY);Mysql是先對外表A執行全表查詢，然後根據uuid逐次執行子查詢，如果外層表是一個很大的表，我們可以想象查詢效能會表現比這個更加糟糕。
一種簡單的優化就是用innerjoin的方法來代替子查詢，查詢語句改為：
Select* from A inner join B ON A.uuid=B.uuid using(uuid) where b.uuid>=3000; 這個語句執行測試不到一秒；
第三：使用JOIN時候，應該用小的結果驅動打的結果（left join 左邊表結果儘量小，如果有條件應該放到左邊先處理，right join同理反向），同時儘量把牽涉到多表聯合的查詢拆分多個query (多個表查詢效率低，容易鎖表和阻塞)。如：
Select * from A left join B A.id=B.ref_id where A.id>10;可以優化為：select * from (select * from A wehre id >10) T1 left join B on T1.id=B.ref_id;
20、exist 代替 in
SELECT * from A WHERE idin (SELECT id from B)
SELECT * from A WHERE id EXISTS(SELECT 1 from A.id= B.id)
in 是在記憶體中遍歷比較
exist 需要查詢資料庫，所以當B的資料量比較大時，exists效率優於in.
in()只執行一次，把B表中的所有id欄位快取起來，之後檢查A表的id是否與B表中的id相等，如果id相等則將A表的記錄加入到結果集中，直到遍歷完A表的所有記錄。
In 操作的流程原理如同一下程式碼
List resultSet={};
Array A=(select * from A);
Array B=(select id from B);
for(int i=0;i<A.length;i++) {
for(int j=0;j<B.length;j++) {
if(A[i].id==B[j].id) {
resultSet.add(A[i]);
break;
}
}
}
return resultSet;
可以看出，當B表資料較大時不適合使用in()，因為它會B表資料全部遍歷一次
如：A表有10000條記錄，B表有1000000條記錄，那麼最多有可能遍歷10000*1000000次，效率很差。
再如：A表有10000條記錄，B表有100條記錄，那麼最多有可能遍歷10000*100次，遍歷次數大大減少，效率大大提升。
結論：in()適合B表比A表資料小的情況
exist()會執行A.length()次，執行過程程式碼如下
List resultSet={};
Array A=(select * from A);
for(int i=0;i<A.length;i++) {
if(exists(A[i].id) { //執行select 1 from B where B.id=A.id是否有記錄返回
resultSet.add(A[i]);
}
}
return resultSet;
當B表比A表資料大時適合使用exists()，因為它沒有那麼多遍歷操作，只需要再執行一次查詢就行。
如：A表有10000條記錄，B表有1000000條記錄，那麼exists()會執行10000次去判斷A表中的id是否與B表中的id相等。
如：A表有10000條記錄，B表有100000000條記錄，那麼exists()還是執行10000次，因為它只執行A.length次，可見B表資料越多，越適合exists()發揮效果。
再如：A表有10000條記錄，B表有100條記錄，那麼exists()還是執行10000次，還不如使用in()遍歷10000*100次，因為in()是在記憶體裡遍歷比較，而exists()需要查詢資料庫，
我們都知道查詢資料庫所消耗的效能更高，而記憶體比較很快。
結論：exists()適合B表比A表資料大的情況
當A表資料與B表資料一樣大時，in與exists效率差不多，可任選一個使用。