在MySQL条件筛选中，IN操作符最常见的用途就是判断某一列的值是否属于一个给定的集合。比如统计平台里状态为已支付、已发货、已完成的三类订单，如果不用IN，就要写成三个OR条件，既啰嗦又容易遗漏括号导致逻辑错误。IN把这种多值匹配收敛成一行条件，可读性更好，也方便后续维护。
一、IN 的基本语法与常见使用方式
从语法上看，IN的写法很直观：expr IN (value1, value2, value3)。其中expr可以是字段名、函数结果或者表达式，括号内则是候选值列表。MySQL在解析时会把这种写法理解成expr = value1 OR expr = value2 OR expr = value3，但二者并不是完全等价，尤其是在列表为空、包含NULL或涉及子查询时，执行逻辑会有差异。
最简单、最稳定的场景是使用固定常量列表。例如查询订单状态为已支付、已发货、已完成中的任意一种，可以这样写：
SELECT order_id, user_id, status
FROM orders
WHERE status IN ('paid', 'shipped', 'delivered');
这种写法比下面使用OR的版本更简洁，而且不容易出现因为少写括号而导致的优先级错误：
SELECT order_id, user_id, status FROM orders WHERE status = 'paid' OR status = 'shipped' OR status = 'delivered';
除了常量列表，IN也支持子查询。比如要查所有下过单的用户信息，可以先从订单表里取出user_id集合，再到用户表里做过滤。这种写法让SQL的意图更接近自然语言：从某张表里取出符合条件的集合，再判断目标字段是否落在该集合中。不过子查询涉及的数据量、索引设计和执行计划，会直接影响查询效率，这也是后面单独讨论的原因。
二、IN 与 NULL 值容易混淆的细节
NULL在MySQL中代表未知值，布尔判断遵循三值逻辑，结果可能是真、假或未知。IN在这里的行为和普通等值比较不同。字段值为NULL时，NULL IN ('a','b')的结果是NULL，而不是0，因此该行不会出现在WHERE筛选结果中，因为WHERE只接受结果为真的行。
更隐蔽的问题出现在列表本身包含NULL时。假设写成status IN ('paid', NULL)，对于status = 'paid'的行，结果为真，可以正常返回；但对于status = 'archived'的行，判断过程是'archived' = 'paid'为假，'archived' = NULL为未知，最终假或未知仍然不是真，所以不会返回。这通常符合预期，但如果你以为IN列表里的NULL会匹配所有未知值，那就理解错了。
相比之下，NOT IN对NULL的敏感度更高。看下面这个例子：
SELECT user_id, user_name
FROM users
WHERE user_id NOT IN (
SELECT user_id
FROM orders
);
如果orders表的子查询结果里包含一个NULL的user_id，那么整个NOT IN判断可能对很多行都返回未知，最终导致查询结果为空。原因是user_id NOT IN (1, 2, NULL)等价于user_id <> 1 AND user_id <> 2 AND user_id <> NULL，而最后一个条件永远为未知，整组AND的结果也就无法为真。实际业务中，订单表的user_id通常不允许为NULL，但如果你在使用NOT IN时突然发现结果为空，第一时间应该检查子查询是否混入了NULL。规避方法也很简单，可以在子查询内部补一个WHERE user_id IS NOT NULL，或者改用NOT EXISTS。
三、IN 子查询的执行过程与性能优化
当IN后面的集合来自子查询时，MySQL优化器会尝试将外查询与子查询转换为半连接处理。半连接的优势在于它可以利用内表的索引快速判断是否存在匹配行，而不是先完整物化子查询结果。对于大部分普通场景，这种转换能显著减少临时结果集的生成成本。
不过，半连接优化并不会在所有情况下生效。如果子查询包含聚合、UNION、GROUP BY等复杂结构，或者子查询结果集非常庞大且无法有效使用索引，优化器可能退化为物化子查询结果，再让外层表逐行去匹配。这时执行计划里经常能看到SUBQUERY节点或者较大的临时表扫描。例如下面这个查询，如果orders表的user_id列没有索引，子查询会产生全表扫描，性能可能急剧下降：
SELECT user_id, user_name
FROM users
WHERE user_id IN (
SELECT user_id
FROM orders
WHERE created_at > '2025-01-01'
);
优化这类SQL的第一步是确认子查询涉及的列是否有合适索引，尤其是外查询与内表关联的字段。对上面的例子，应当在orders(user_id, created_at)上建立复合索引，让子查询可以按时间过滤后快速回表，或者在可行时改写成EXISTS形式：
SELECT u.user_id, u.user_name
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.user_id
AND o.created_at > '2025-01-01'
);
EXISTS的语义是判断是否存在满足条件的行，不关心子查询具体返回值。这种写法对NULL值天然不敏感，而且相关子查询一旦在内表上找到匹配就可以提前返回，在某些数据分布下比IN更稳定。使用EXPLAIN查看执行计划时，如果看到外查询和内表的连接类型为ref，并且使用了合理的索引，通常说明优化已经达到预期。
四、NOT IN 的替代方案与使用建议
在业务里需要排除一组值或者查找不存在关联记录的数据时，很多SQL会直接用NOT IN。这种写法在小数据量下没有问题，但如果子查询可能返回NULL，或者内表数据量持续增长，NOT IN的语义不稳定和性能下降就会逐渐暴露出来。推荐的替代方式主要有两种：NOT EXISTS和LEFT JOIN ... WHERE ... IS NULL。
NOT EXISTS通过相关子查询判断匹配行是否存在，不存在时才返回外层记录：
SELECT u.user_id, u.user_name
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.user_id
);
这种写法不受子查询中NULL值的影响，语义也更容易理解。另一种写法是使用左连接：
SELECT u.user_id, u.user_name FROM users u LEFT JOIN orders o ON o.user_id = u.user_id WHERE o.user_id IS NULL;
两者在性能上没有绝对优劣，关键仍然取决于索引设计和数据分布。NOT EXISTS通常更适合大的外表配合小的内表，或者内表关联列有唯一索引的情况。左连接在优化器眼里会把两张表完整关联后再过滤，如果orders表很大，这个连接过程可能会产生大量中间结果。因此建议用EXPLAIN对比两种写法的执行计划，而不是凭感觉选择。
总体来看，IN适合常量集合或能够有效利用索引的小型子查询，NOT IN要谨慎处理可空字段，EXISTS与NOT EXISTS在关联判断场景下往往语义更安全。把这些边界条件理解清楚，比单纯记住语法更有价值。