A. sql中in和=的區別，大數據量哪個性能更好
大數據in的性能更好，=需要多次條件判斷，小數據=更好
B. sql in好還是or好，我的條件有五六個以上，但用or的話感覺太長了，不知道哪個效率高點
自己沒測試過，這兩篇文章看著比較靠譜：
網頁鏈接作者結論：如果in和or所在列有索引或者主鍵的話，or和in沒啥差別，執行計劃和執行時間都幾乎一樣。在沒有索引的情況下，隨著in或者or後面的數據量越多，in的效率不會有太大的下降，但是or會隨著記錄越多的話性能下降非常厲害
網頁鏈接作者結論：總體來說，In的效率更高一些。
C. sql in語句的性能問題
每個機票訂單含有多個票，用符合條件的訂單List，去查詢對應的票List。
兩張表的關聯方式是用一個特性的key關聯，其中包含，代理商區分標余啟喊志，訂單號，訂單類型等，是一個長度在30~50之間的varchar
遍歷list一條一條查的話，IO太多，顯然不合適旁檔。我們就想到用in來實現批量查詢
在beta測試時，庫中表裡只有一個月的數據，大約在1000萬左右，測試時沒有發現問題。
到了線上之後，發現查詢數據非常慢，兩萬左右的in條件，查詢起來，時間在10分鍾左右，顯然出現了慢查詢。
針對這個問題，做了幾個測試，看了下執行計劃，如下所示
事實上我們看到，在in語句中數據量不大的情況下，索引是有效的，不過這個數量已經是極限了。
下面是我的語句
這里在in裡麵包含了三萬條數據，索引實效了。
這里我們首先想到，強制使用索引會不會有所幫助如下
但是，事實上並沒有效果，這是結果
解下來我們分析一下，兩個問題，索引為什麼會失效
這個問題需要從兩個方面入手
1.索引區豎野分度
2.預計掃描行數
3.優化器的選擇
先看第一個，索引的區分度，經過隨機采樣，看著內容還是很高的。
預計掃描行數
預計掃描行數的話，如前兩圖所示，基本都走了全表掃描。
優化器的選擇
優化器選擇時，衡量了回表等操作，綜合考慮，這里沒有辦法繼續下去了，只能問到DBA了。
在數據表大時，索引負重較大，同樣的情況下，in語句裡面數據條數夠大時，索引會失效，可以通過force index嘗試一下，不過成功的可能行很小，盡量分批去查找，批次數量可配置。
D. sql中in（）效率低
對於in 和 exists的區別: 如果子查詢得出的結果集記錄較少，主查詢中的表較大且又有索引時應該用in, 反之如果外層的主查詢記錄較少，子查詢中的表大，又有索引時使用exists。其實我們區分in和exists主要是造成了驅動順序的改變（這是性能變化的關鍵），如果是exists，那麼以外層表為驅動表，先被訪問，如果是IN，那麼先執行子查詢，所以我們會以驅動表的快速返回為目標，那麼就會考慮到索引及結果集的關系了 ，另外IN時不對NULL進行處理。
E. sql語句中條件查詢里in、like、及=三個的效率怎麼樣
1、如果條件欄位都是非索引欄位，那麼效率都差不多，就看結果大小。
2、有差別的在於條件欄位是索引欄位時：
=在所以的情況下都會進行索引掃描，所以效率總是高的。
like 當模糊查詢為右模糊，比如'abc%'時，掃描索引，高效。
當模糊查詢含左模糊時，比如'%abc',進行全表掃描，低效。
in的作用等同於or ，也是進行索引掃描，高效。
另外，in還可以連接查詢結果集，這時往往會和exists做比較。
a、 select * from t1 where f1 in (select f1 from t2 where t2.fx='x')，
其中子查詢的where里的條件不受外層查詢的影響，這類查詢一般情況下，自動優化會轉成exist語句，也就是效率和exist一樣。
b、 select * from t1 where f1 in (select f1 from t2 where t2.fx=t1.fx)，
其中子查詢的where里的條件受外層查詢的影響，這類查詢的效率要看相關條件涉及的欄位的索引情況和數據量多少，一般效率不如exists,數據量大時，效果就更加明顯。
F. sql中in 的效能好還是join的效能好
肯定派埋判是第一種快啊。
第一種一個語句，和第二種for裡面單個語句的執行效率差異不大的。
in 語句，就是相當於 多個 or，塵改執行就是一次數據遍液李歷，而for裡面，幾個語句是幾次遍歷。
G. 關於sql中in 和 exists 的效率問題，in真的效率低嗎
exists效率快，因為培慧會吵盯用到索引，並且是有數據就返回，而in會每個配碰答都運算，並且不會用到索引。用不用索引，是指使用的列有索引的情況。
H. 記一次Sql執行從17分鍾到3秒的優化
同事小A拿來了一段sql語句問我說為什麼執行特別慢，跑一次要十多分鍾。我試了一下，好傢伙，最慢17分鍾。語句如下：
其中TABLE1是一個數據記錄表，VEMPLOYEE是一個員工表的視圖，我看了一下視圖定義，徹底被震驚了
小A解釋說，客戶要求有好多地方頁面展示的時候要屏蔽一些員工，所以就直接搞了個員工視圖來做統一的過濾處理。
在sql中使用 IN 或者 NOT IN 的性能是非常差的，至於具體原因，好多大佬解釋的很清楚了，我就不再贅述。帶顫那麼第一步，就是使用LEFT JOIN替換掉語句里邊的NOT IN
首先創建一個表 IGNORE_EMP_ID 存儲需要忽略的員工ID，只有一個ID列，修改視圖創建語句如下：
展示一下 LEFT JOIN 替換 NOT IN 的執行過程，假設EMPLOYEE表有ID為慶模1、2、3這三個員工，需要忽略的ID有1、3這兩個
時得到的數據為：
修改的方法告訴了小A，過了幾分鍾，我就問他改的咋樣，他說正在往新建的 IGNORE_EMP_ID 表插數據。那好吧，我來幫忙插數據好了。
前面介紹過原來的sql里邊都是一行一個數字排列的，我們把 NOT IN 里邊的所有譽行緩ID復制出來到txt文件
然後回車拉至最後一行，復制出B列所有sql執行即可。
I. 較大量數據的多表關聯，SQL JOIN 和 IN 性能區別大嗎
JOIN表示連備族接兩個表，分為外連接和內連接，通常用於帶出關聯關系的其他表的欄位信息，比如我這里有用戶ID想查出，用畢褲戶的姓名，可以外仿數弊連接用戶表，帶出姓名欄位。
IN這個關鍵字有性能要求，如果IN裡面的選項大於1000個，性能下降的非常快，可以用exist來代替 ，具體用法可以查一下，資料有一堆。
J. 關於sql中in 和 exists 的效率問題，in真的效率低嗎
關於sql中in 和 exists 的效率問題，in真的效率低嗎
in和exists
in 是把外表和內表作hash 連接，而exists是對外表作loop循環，每次loop循環再對內表進行查詢。
如果兩個表中一個較缺哪物小，一個是大表，則子查詢表大的用exists，子查詢表小的用in：
例如緩沒：表A（小表），表B（大表）1：select * from A where cc in (select cc from B)
效率伏液低，用到了A表上cc列的索引；select * from A where exists(select cc from B where cc=A.cc)
效率高，用到了B表上cc列的索引。