SQL優化關於or與in使用

阿新 • • 發佈：2019-02-02

網上有很多人都在談論or與in的使用，有的說二者沒有什麼區別，其實不然，估計是測試做的不夠，其實or的效率為O(n)，而in的效率為O(log2n)，當基數越大時，in的效率就能凸顯出來了。

有人做了這麼一組實驗(測試庫資料為1000萬條記錄)：A組分別用or與in查詢3條記錄，B組分別用or與in查詢120條記錄,C組分別用or與in查詢500條記錄,D組分別用or與in查詢1000條記錄.

第一種情況，目標列為主鍵的情況，4組測試執行計劃一樣，執行的時間也基本沒有區別。
A組or和in的執行時間： or的執行時間為：0.002s     in的執行時間為：0.002s
B組or和in的執行時間： or的執行時間為：0.004s     in的執行時間為：0.004s
C組or和in的執行時間： or的執行時間為：0.006s     in的執行時間為：0.005s
D組or和in的執行時間： or的執行時間為：0.017s     in的執行時間為：0.014s

第二種情況，目標列為一般索引的情況，4組測試執行計劃一樣，執行的時間也基本沒有區別。
A組or和in的執行時間： or的執行時間為：0.002s     in的執行時間為：0.002s
B組or和in的執行時間： or的執行時間為：0.006s    in的執行時間為：0.005s
C組or和in的執行時間： or的執行時間為：0.008s     in的執行時間為：0.008s
D組or和in的執行時間： or的執行時間為：0.020s     in的執行時間為：0.019s

第三種情況，目標列沒有索引的情況，4組測試執行計劃就不一樣，執行的時間也有了很大的區別。
A組or和in的執行時間： or的執行時間為：5.016s    in的執行時間為：5.071s
B組or和in的執行時間： or的執行時間為：1min 02s     in的執行時間為：5.018s
C組or和in的執行時間： or的執行時間為：1min 50s     in的執行時間為：5.010s

D組or和in的執行時間： or的執行時間為：6min 13s in的執行時間為：5.047s

結論：

in和or的效率，取決目標條件列是否有索引或者是否是主鍵，如果有索引或者主鍵效能沒啥差別，如果沒有索引，in的效能要遠遠優於or.

SQL優化關於or與in使用

網上有很多人都在談論or與in的使用，有的說二者沒有什麼區別，其實不然，估計是測試做的不夠，其實or的效率為O(n)，而in的效率為O(log2n)，當基數越大時，in的效率就能凸顯出來了。有人做了這麼一組實驗(測試庫資料為1000萬條記錄)：A組分別用or與in查詢3條記錄

Sql中EXISTS與IN的使用及效率

in 和exists 對於以上兩種查詢條件，in是把外表和內表作hash 連線，而exists 是對外表作loop 迴圈，每次loop 迴圈再對內表進行查詢。一直以來認為exists 比in 效率高的說法是不準確的。在不同的情況下，exists與in的效能各有優缺項，如果查詢的兩個表大小相當，那麼用in

關於sql中or與and的執行順序

<select id="countAssetTab" resultType="Integer" parameterType="HashMap"> SELECT COUNT(1) FROM TTRD_ASSET_MANAGE_PLAN_EXTEND

sql語句or與union all的執行效率比較

當SQL語句有多個or語句時，可以考慮使用union或者union all代替來提高速度。使用or的SQL語句往往無法進行優化，導致速度變慢。但這不是固定的，有時候使用or速度會更快些。具體情況還要經過測試為準。如果加索引的話，也可能實現速度優化。實驗表格如下,實

SQL中EXISTS與IN的效率問題

一起學習一下；有兩個簡單例子，以說明 “exists”和“in”的效率問題1) select * from T1 where exists(select 1 from T2 where T1.a=T2.a) ; T1資料量小而T2資料量非常大時，T1<<T

面試被問之-----sql優化中in與exists的區別 Mysql中 in or exists not exists not in區別（網路整理） Sql語句中IN和exists的區別及應用 [筆記] SQL效能優化 - 避免使用 IN 和 NOT IN

曾經一次去面試,被問及in與exists的區別,記得當時是這麼回答的:''in後面接子查詢或者(xx,xx,xx,,,),exists後面需要一個true或者false的結果",當然這麼說也不算錯,但別人想聽的是sql優化相關,肯定是效率的問題,只是那個時候確實不知道它們在sql優化上的區別,只知道用in會進

sql優化之in與

在我們開發過程中，初期可能不會去太關注我們自己寫的sql語句的效率怎麼樣，因為總是覺得可以拿取到資料就算是ok了，可能也會注意一下你的sql執行的時間，但是在開發的過程中因為資料量的原因，其實你不去了解一下sql的一些優化的手段其實是無法感知你的sql的效率問題

二十七、IN與EXISTS對SQL優化的影響

IN與EXISTS對SQL優化的影響 select * from v$version; drop table em

SQL優化--使用 EXISTS 代替 IN 和 inner join來選擇正確的執行計劃

tool pos inner ner 使用邏輯讀 rda jpg 分享在使用Exists時，如果能正確使用，有時會提高查詢速度： 1，使用Exists代替inner join 2，使用Exists代替 in 1，

SQL優化- in和not in

audit roc RoCE AI 時間 pro 執行 code ESS in不會導致索引失效，但最終數據庫會將in語句解析為or語句，eg： select * from T_MAIN_PROCESS t where t.audit_status_code in (‘05‘

大數據量數據庫設計與優化方案(SQL優化)

把他 like 後者結果集表鎖 ted detail 出了解決方案轉自：http://blog.sina.com.cn/s/blog_6c0541d50102wxen.html 一、數據庫結構的設計如果不能設計一個合理的數據庫模型，不僅會增加客戶端

阿里P8架構師談：MySQL資料庫的索引原理、與慢SQL優化的5大原則

MySQL憑藉著出色的效能、低廉的成本、豐富的資源，已經成為絕大多數網際網路公司的首選關係型資料庫。雖然效能出色，但所謂“好馬配好鞍”，如何能夠更好的使用它，已經成為開發工程師的必修課，我們經常會從職位描述上看到諸如“精通MySQL”、“SQL語句優化”、“瞭解資料庫原理”等要求。我們知道一般

小米開源的自研智慧SQL優化與改寫工具SOAR使用指南

本文簡述了SOAR的下載安裝和使用方法，並介紹了SOAR的基礎設定和應用的四個場景。在10月20日的開源先鋒日（OSCAR）上，小米開源了自研的SOAR（SQL Optimizer And Rewriter）。這是一款智慧SQL優化和改寫工具，開發人員可以直接通過

論SQL優化重要性及我與大佬差距

論SQL優化重要性及我與大佬差距今天快下班，測試報告我功能上的不合理性，認為按照被保人姓名或車牌號查詢，無法區分英文名和車牌號的區別。我解釋說SQL響應時間遇到問題，所以用業務區分，寫兩條SQL。 &nbs

sql joins 與 in

in：先篩查出結果集，再在結果集中篩選。 select * from A where A.id in（select B.id from B where B.DZ='110' ） and A.DZ='110'

Oracle與Mysql等資料庫通用SQL優化技巧

a. 資料表的處理順序 oracle 在解析一個查詢語句FROM後面的一系列資料表是按照從右往左的順序進行的.也就是說最後的資料表將是最先被oracle處理的,所以我們在寫多個表關聯的查詢語句時,把資料量最小的表或者是經過條件篩選後得到資料量最小的表放到最後,資料量大的表就放在最前面. select col1

sql優化in語句

在很多時候我們在sql中會用到in語句，in語句會使得sql查詢不使用索引，這也大大減低了sql執行的效率，為了能夠讓sql在查詢中使用索引，有很多種方式可以優化，比如如果in中的型別是確定值，那麼可以用欄位=確定值多個條件直接用or連線，這樣也可以優化這

遍歷資料庫表（ACCESS/SQL SERVER）的方法。SQL中IN,NOT IN,EXISTS,NOT EXISTS的用法和差別。資料庫中的exists與in

遍歷資料庫表（ACCESS/SQL SERVER）的方法以前在網上查詢遍歷SQL資料庫表的方法，可以用 select name from sysobjects where xtype='u' and (not name LIKE 'dtproperties') 來查詢SQL的系

高階SQL優化(二) ——《12年資深DBA教你Oracle開發與優化——效能優化部分》

u正確合適的索引是查詢優化效能的首選 u索引是表的索引列排序後的小型化拷貝，會增加儲存開銷，因此會帶來Insert、Update、Delete的額外開銷 u一個表可以有一個索引，也可以有多個索引，往往過多的索引或不恰當的索引帶來的負面性能更多 u表索引的設計初衷，往往在40%甚至更高的情況下與最終的實

mysql sql優化與索引

寫在前面：索引對查詢的速度有著至關重要的影響，理解索引也是進行資料庫效能調優的起點。考慮如下情況，假設資料庫中一個表有10^6條記錄，DBMS的頁面大小為4K，並存儲100條記錄。如果沒有索引，查詢將對整個表進行掃描，最壞的情況下，如果所有資料頁都不在記憶體，需要讀取10^4個頁面，如果這10^4個頁面在磁

SQL優化關於or與in使用

相關推薦