MySQL的in语句和or哪个执行效率更高?-原创手记-慕课网

一、背景

今天有个朋友问题“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）。

如果都是数字和字母，则按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格式电子书等。

难道不感动吗？难道有理由不去下载吗？

四、总结

本文简单研究了MySQL中In和or的效率问题，教大家如何去研究这一类问题，后面类似的问题都可以沿着这个思路搞。

大家如果不研究到源码或者官方文档就不要太过轻信。

另外研究这类问题时相关的问题也要顺便了解和研究一下。

另外大家开发过程中一定优先看核心技术展源码，优先看官方文档而不是不想就问，不想就去百度。

另外不一定要等到遇到问题再去查，没事也可以主动去看。

创作不易，如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。