标签：很多 引擎 字符 number you 链接 ted wan 人做
一、背景
今天有个朋友问题“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 the IN list is only limited by the 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 large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for 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格式电子书等。
难道不感动吗？难道有理由不去下载吗？
标签：很多 引擎 字符 number you 链接 ted wan 人做
原文地址：https://www.cnblogs.com/hnzkljq/p/12620949.html
