mysql如何使用in条件查询

检查 IN 条件非常简单。
只需检查该值是否在列表中即可。

我上周刚刚照顾了一个。
查看订单表格，订单号为1 2 3 , 4 5 6 , 7 8 9
SELECT FROM Orders WHERE id IN (1 2 3 , 4 5 6 , 7 8 9 )
说白了，就是对应多个OR连接在一起。
示例：id=1 2 3 或 id=4 5 6 或 id=7 8 9
子查询也可以使用IN。
例如，查看订单状态为“已完成”的用户。

SELECT name FROM users WHERE id IN (SELECT user_id FROMorders WHERE status='completed')
也可以使用 NOT IN。
我检查了订单号不是2 3 4 或5 6 7
SELECT FROMorders WHERE id NOT IN (2 3 4 , 5 6 7 )
但是如果子查询包含NULL，就会有问题。
子查询中最好不要有NULL。

不要让 IN 列表太长。
超过几百就会慢。
可以考虑临时表或者JOIN。

例如，使用JOIN查看已“完成”订单的用户。

SELECT DISTINCT u.name FROM Users u JOINorders o ON u.id=o.user_id WHERE o.status='completed'
请记住在检查 ID 字段时添加索引。
它可以快得多。
但当数据量较大时
IN 速度较慢。
使用JOIN比较可靠。

如果子查询返回NULL，可以使用IS NOT NULL 进行过滤。

或者使用组合 LEFT JOIN + IS NULL。
自己尝试一下。

mysql中in和等于的用法 mysql in与=使用场景

说实话，我之前也思考过这个问题。
我们来谈谈现实生活中的一个场景。
我们团队在处理电商后台需求时，需要查看某些VIP用户的订单。
一开始我输入IN直接使用，但是数据量一增加就卡住了，后台一片混乱。

有趣的是，IN用得好不好，取决于它的价值。
例如，如果某个活动需要筛选三个特定产品，则可以将其写为 IN(1 ,2 ,3 )。
但如果有新闻，比如你需要查看当天所有的热门单品，你刚IN就会被骗。
我亲眼目睹过数百个ID被强制放入括号中，导致数据库后端CPU飙升。
后来改用子查询，或者插入临时表再IN，速度连零点几秒都没有。

说起来=，这东西只是一个老好人而已。
检查单个用户 ID = 1 00，或订单状态 =“已付款”。
如果覆盖索引的话，速度会很快。
我当时负责的运维小伙伴说，他最喜欢的调整SQL的方式就是给=加索引，这比什么都好。
记得有一次查看某个用户的操作日志，直接添加单列索引。
查询时间从秒变为毫秒。

在可读性方面，IN 占据上风。
例如，如果您需要检查用户是否被列入黑名单，IN('user1 ','user2 ') 看起来比编写一堆 OR 条件干净得多。
但维护起来却很头疼。
当列表改变时，SQL也必须相应改变。
后来我们创建了一个黑名单表并使用 JOIN 将其关联起来。
虽然写法有点复杂，但是后续用户的增删改查只需要操作表即可，不需要接触SQL。

随着数据量的增加，IN和=之间的差距变得明显。
有一个项目，使用IN来匹配百万级别的ID集，CPU运行率为1 00%。
最后通过使用JOIN连接分类表解决了。
JOIN 实际上非常酷。
它将 IN 值转换为表，然后将其与主表连接，这通常比直接 IN 更快。

说白了，这件事没有标准答案。
要检查单个值，请使用 =，这不起作用。
那么多值匹配呢？小的可以直接IN，大的一定要找出来。
记得有一篇技术博客说，当IN值超过5 00时，性能就会崩溃。
这个数字我记不太清楚了，建议你自己测试一下。
最重要的是你不仅仅看性能，还要结合实际的业务场景。
比如有些系统用户量波动较大，那么JOIN可能会更稳定。
有的查询率很高，直接用IN就可以了。

我从来没有亲自在这方面运行过NoSQL IN，所以我不知道它与MySQL有什么异同。
我记得数据在X左右，但我建议你查看最新版本的性能曲线。
反正我十年来IN和=的选择还是靠测试和经验。
没有灵丹妙药可以治愈所有疾病。