一、背景
今天有個朋友問題“MySQL的In語句和or哪個效率更高一些？”
對于這個問題大多數人可能都是通過百度直接拿答案，然後就沒然後了。
本文将對此問題簡要進行分析。
二、分析
接下來我們要幹啥？？我們應該去百度對吧？！
别急，我們的套路是想想有哪些可以查詢和解決這個問題的途徑。
2.1 自己動手豐衣足食
自己建立一個表，然後塞n多資料，分表将查詢的字段無索引和建立唯一索引，建立普通索引都對比一下。
（我這裡暫時不做）
可以得到一些親身的經驗。
2.2 看源碼
MySQL明顯不是Java寫的，而且捯饬源碼不容易，我們還是先放棄吧。
2.3 搜尋引擎
我們搜到了一篇，有類似的https://www.cnblogs.com/lixiuyuan999/p/6368871.html
做了一些實驗結論如下：
結論：
1.in或or在字段有添加索引的情況下，查詢很快，兩者查詢速度沒有什麼差別；
2.in或or在字段沒有添加索引的情況下,所連接配接的字段越多(1or2or3or4or......)，or比in的查詢效率低很多
都有一些其他的類似結論，确實可以直接得到答案挺省事，但是總感覺不太權威。
2.4 SOF
其實可以在google裡搜，但是你懂得....
我們還是從StackOverFlow裡搜吧。
我們搜到了一些答案，典型的如下：
https://stackoverflow.com/questions/782915/mysql-or-vs-in-performance
我們知道有人做了實驗，通過他的對比，也是In的效率更高。
還有這個回答
我們了解了更多，知道了在很多資料庫裡In和or是等價的，因為他們邏輯是相等的。
但是在MySQL中會對in中的清單排序，排序用的是二分查找來判斷是否在清單中。in的時間複雜度是O(logn)而or的時間複雜度是O(n)，這就意味着In的效率更高。
另外還有人說範圍查找比in效率還高！！
還有一些其他的說法，讓我們大開眼界。
雖然如此，我們還是不放心怎麼辦？？處女座，強迫症腫麼辦？？
2.5 官方文檔大法
https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_in
和上面的2.4第二個解釋非常類似。效率很高。
三、問題來了
總體來說，In的效率更高一些。
那麼MySQL中in有沒有長度限制？？？
前面幾個步驟就不重複了，直接看官方手冊https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_in
The number of values in thelist is only limited by theIN
max_allowed_packet
value.
in的資料量受限于
max_allowed_packet的值。
很貼心的給了我們一個超連結https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_allowed_packet
max_allowed_packet表示最大允許接收的包大小。mysql 8.02及其之前版本預設大小是4194304位元組（
即4M
）。
到此結束了？？no!!
大概可以傳多長的字元呢？？
如果都是數字和字母，則按一個字元1位元組，預設可傳400多萬個字元，是以正常使用不用擔心。
啥時候需要調呢？
官方貼心的告訴你：
You must increase this value if you are using largecolumns or long strings. It should be as big as the largestBLOB
you want to use. The protocol limit forBLOB
max_allowed_packet
is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.
官方貼心地提示你：
如果你用大blob列或者長字元串必須設定大一些。應該是你可能用到的最大BLOB的大小。協定限制1GB。這個值必須設定為1024的倍數，如果不是則自動取最近的1024的倍數位元組。
結束了？
請看官方線上文檔的左下角，官方很貼心得為我們提供了PDF格式的電子書，提供了HTML格式電子書等。
難道不感動嗎？難道有理由不去下載下傳嗎？
四、總結
本文簡單研究了MySQL中In和or的效率問題，教大家如何去研究這一類問題，後面類似的問題都可以沿着這個思路搞。
大家如果不研究到源碼或者官方文檔就不要太過輕信。
另外研究這類問題時相關的問題也要順便了解和研究一下。
另外大家開發過程中一定優先看核心技術展源碼，優先看官方文檔而不是不想就問，不想就去百度。
另外不一定要等到遇到問題再去查，沒事也可以主動去看。
創作不易，如果覺得本文對你有幫助，歡迎點贊，歡迎關注我，如果有補充歡迎評論交流，我将努力創作更多更好的文章。