MySQL到底是join性能好，还是in一下更快呢？

发布时间：2025-11-05 04:09:10 来源：云智核 作者：应用开发

大家好呀，到底我是性n下楼仔。

今天发现一篇很有意思的更快文章，使用 mysql 查询时，到底是性n下使用 join 好，还是更快直接 in 更好，这个大家工作时经常遇到。到底

为了方便大家查看，性n下文章我重新进行了排版。更快

我没有直接用作者的到底结论，感觉可能会误导读者，性n下而是更快根据实验结果，给出我自己的到底建议。

不 BB，性n下上目录：

图片

01 背景

事情是更快这样的，去年入职的新公司，之后在代码 review 的时候被提出说，不要写 join，join 耗性能还是慢来着，当时也是真的没有多想，服务器租用那就写 in 好了。

最近发现 in 的数据量过大的时候会导致 sql 慢，甚至 sql 太长，直接报错了。

这次来浅究一下，到底是 in 好还是 join 好，仅目前认知探寻，有不对之处欢迎指正。

以下实验仅在本机电脑试验。

02 表结构

2.1 用户表

图片

2.2 订单表

图片

03 千条数据情况

数据量：用户表插一千条随机生成的数据，订单表插一百条随机数据

要求：查下所有的订单以及订单对应的用户

耗时衡量指标：多表连接查询成本 = 一次驱动表成本 + 从驱动表查出的记录数 * 一次被驱动表的成本

3.1 join

select order.id, price, user.name from order join user on order.user_id = user.id;

图片

3.2 in

select id,price,user_id from order;

图片

select name from user where id in (8, 11, 20, 32, 49, 58, 64, 67, 97, 105, 113, 118, 129, 173, 179, 181, 210, 213, 215, 216, 224, 243, 244, 251, 280, 309, 319, 321, 336, 342, 344, 349, 353, 358, 363, 367, 374, 377, 380, 417, 418, 420, 435, 447, 449, 452, 454, 459, 461, 472, 480, 487, 498, 499, 515, 525, 525, 531, 564, 566, 580, 584, 586, 592, 595, 610, 633, 635, 640, 652, 658, 668, 674, 685, 687, 701, 718, 720, 733, 739, 745, 751, 758, 770, 771, 780, 806, 834, 841, 856, 856, 857, 858, 882, 934, 942, 983, 989, 994, 995);

其中 in 的是order查出来的所有用户 id。

图片

如此看来，分开查和 join 查的成本并没有相差许多。

3.3 并发场景

主要用php原生写了脚本，用ab进行10个同时的请求，看下时间，进行比较。

下面是 join 查询的免费信息发布网执行脚本：

图片

下面是 in 查询的执行脚本：

图片

看时间的话，明显 join 更快一些。

04 万条数据情况

user表现在10000条数据，order表10000条试下。

4.1 join

图片

4.2 in

order 耗时：

图片

user 耗时：

图片

4.3 并发场景

join 耗时：

图片

in 耗时：

图片

数据量达到万级别，非并发场景，in 更快，并发场景 join 更快。

05 十万条数据情况

随机插入后user表十万条数据，order表一百万条试下。

5.1 join

图片

5.2 in

order 耗时：

图片

user 耗时：

order查出来的结果过长了...

5.3 并发场景

join 耗时：

图片

in 耗时：

图片

数据量达到十万/百万级别，非并发场景，in 过长，并发场景 join 更快。

06 总结

实验结论：

下面是楼仔给出的一些建议。

当数据量比较小时，建议用 in，香港云服务器虽然两者的性能差不多，但是 join 会增加 sql 的复杂度，后续再变更，会非常麻烦。

当数据量比较大时，建议用 join，主要还是出于查询性能的考虑。

不过使用 join 时，小表驱动大表，一定要建立索引，join 的表最好不要超过 3 个，否则性能会非常差，还会大大增加 sql 的复杂度，非常不利于后续功能扩展。

相关文章