在MySQL中，IN操作符用于判断某个表达式的值是否在给定的列表或子查询结果中。它的基本形式是 expression IN (value1, value2, ...)，当表达式的值等于列表中任意一个值时，条件成立。例如查询编号为1、3、5的用户，可以写成 WHERE user_id IN (1, 3, 5)，这比用多个OR连接条件要清晰得多。除了静态列表，IN后面还可以跟一个子查询，让过滤条件动态地从另一张表中获取。理解IN的执行逻辑和边界情况，是写出正确且高效SQL的重要基础。
一、IN的基础语法与等价OR展开
IN最常见的用法是在WHERE子句中指定一个值列表。语法如下：
SELECT column1, column2 FROM table_name WHERE column_name IN (value1, value2, value3);
这条语句会返回column_name等于value1、value2或value3中任意一个值的所有行。在逻辑上，它等价于：
SELECT column1, column2 FROM table_name WHERE column_name = value1 OR column_name = value2 OR column_name = value3;
虽然两者结果相同，但IN列表通常更简洁，尤其在需要匹配的值较多时优势明显。MySQL解析器会对IN列表进行排序和去重，然后通过范围扫描或索引查找来执行。如果column_name上有索引，优化器可能将其转换为多个等值条件的OR，再合并索引访问，也可能直接使用range访问方式。
需要注意的是，IN列表中的值类型最好与列类型一致，否则会发生隐式类型转换。比如列是字符串类型，却传入数字列表，虽然MySQL会尝试转换，但可能导致索引失效。另外，空列表IN ()在MySQL中不合法，会直接报语法错误。若要表示“不匹配任何值”，可使用WHERE 1 = 0或WHERE column IN (NULL)之类的方式，但后者受NULL语义影响，通常不会返回任何行。
二、IN子查询的典型场景与执行机制
IN后面除了静态列表，还经常接子查询。例如查询所有有订单的用户信息：
SELECT user_id, user_name
FROM users
WHERE user_id IN (
SELECT DISTINCT user_id
FROM orders
WHERE order_status = 'completed'
);这条语句先执行内层子查询，得到已完成订单对应的用户ID集合，再驱动外层查询返回匹配用户。在MySQL 5.6之前，这种IN子查询可能被实现为相关子查询，即外层每一行都执行一次内层查询，性能较差。从5.6开始，优化器引入了半连接（semi-join）优化，能够将IN子查询转换为内部JOIN，利用索引和物化策略大幅提升性能。例如上面的查询可能被改写为users与orders的内连接，并自动去重。
使用IN子查询时，关键要保证子查询返回的是一列，且列的类型与左侧表达式类型兼容。如果子查询返回多列，会报“Operand should contain 1 column(s)”错误。另一个易错点是子查询结果中包含NULL：当列表包含NULL时，IN的判断结果是TRUE、FALSE或NULL，这会影响最终过滤效果。接下来详细讨论NULL带来的陷阱。
对于大数据量场景，如果子查询结果集非常大，IN列表也可能占用较多内存。MySQL会尝试将子查询结果物化到临时表并建立索引，但如果结果过大，可能落盘。此时应评估是否可以用EXISTS或JOIN替代，或者给子查询涉及的表增加合适索引，减少扫描成本。
三、NOT IN与NULL的经典陷阱及替代方案
NOT IN的逻辑与IN相反，用于排除列表中的值。但很多人在使用NOT IN子查询时遇到过“明明应该返回数据，结果却为空”的现象。根本原因在于NULL的参与。考虑如下数据：orders表中user_id列存在一个NULL值，现在要查询没有完成过订单的用户：
SELECT user_id, user_name
FROM users
WHERE user_id NOT IN (
SELECT user_id
FROM orders
WHERE order_status = 'completed'
);如果子查询返回的user_id列表中有NULL，那么对于外层某一行，user_id NOT IN (1, 2, NULL)实际上被展开为：
user_id != 1 AND user_id != 2 AND user_id != NULL;
问题在于user_id != NULL的结果既不是TRUE也不是FALSE，而是NULL（未知）。在SQL三值逻辑中，TRUE AND NULL结果为NULL，FALSE AND NULL结果为FALSE，因此整行条件不会被判定为TRUE，外层查询得不到任何行。这是NOT IN最常见、也最隐蔽的陷阱。
要避免这个问题，有几种方案。最简单的是在子查询中过滤掉NULL，例如加上WHERE user_id IS NOT NULL。但更推荐的做法是使用NOT EXISTS：
SELECT user_id, user_name
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.user_id
AND o.order_status = 'completed'
);NOT EXISTS使用关联子查询，当内层找不到匹配行时，条件成立。它不受NULL值干扰，而且通常能更好地利用索引。NOT IN在列表明确且无NULL时仍然可用，但只要涉及子查询，就要警惕NULL。如果业务上user_id列允许NULL，建议优先使用NOT EXISTS。
四、IN的性能优化：索引、EXISTS与JOIN的取舍
IN列表本身通常能利用索引进行范围扫描或等值查询。例如WHERE id IN (10, 20, 30)在id主键上会走range访问，效率很高。但当列表值非常多，比如几百上千个常量，优化器可能选择全表扫描，或者索引合并成本上升。实际开发中，若IN列表长度过大，建议将常量集插入临时表，然后使用JOIN：
CREATE TEMPORARY TABLE tmp_ids (id INT PRIMARY KEY); INSERT INTO tmp_ids VALUES (10), (20), (30); SELECT t.* FROM target_table t JOIN tmp_ids tmp ON t.id = tmp.id;
这种做法让MySQL可以利用关联表的索引和统计信息，且临时表可复用。对于IN子查询，MySQL优化器会根据子查询结果大小、外层表大小以及索引情况，在半连接物化、EXISTS策略、表拉出等策略中选择。通常IN子查询适合外层表大而内层结果集小的场景，因为可以先物化内层结果，再通过索引探测外层。
与EXISTS相比，IN和EXISTS在逻辑上有细微差别，优化后的执行计划可能相同，也可能不同。EXISTS关心内层是否存在匹配行，一旦找到即可返回，适合内层表大且有索引的场景；IN通常先求值子查询，适合内层结果集较小的场景。实际优化器会基于成本改写，因此很多情况下两者性能接近。判断时，可以使用EXPLAIN查看执行计划，观察是否出现Using temporary、Using filesort或DEPENDENT SUBQUERY等不利标志。必要时在关联列上建立索引，或者改写为JOIN降低复杂度。
最后，注意IN列表中包含NULL时，IN本身不会报错，但结果可能不符合直觉。例如WHERE id IN (1, 2, NULL)对于id = 3返回NULL，该行被过滤；对于id = 1返回TRUE，该行保留。NOT IN如上所述直接无结果。因此，编写SQL时应明确列是否允许NULL，必要时在查询前清理数据或使用IS NULL条件补充逻辑。