在编写SQL查询时，我们经常需要筛选出某一列等于多个可能值之一的记录。最直观的写法是用一串OR条件拼接，比如country='中国' OR country='美国' OR country='日本'。这种写法在值少的时候看不出问题，可一旦值列表变长，语句既臃肿又难以维护，某些数据库下还会影响索引的使用。SQL标准提供的IN操作符正是为这种场景设计的，它能让语句更简洁，也往往带来更好的执行计划。本文将系统讲解IN操作符的用法、它与OR的本质区别以及实际使用中的进阶技巧。
一、IN操作符的基本语法与常见用法
IN操作符用于判断某个表达式的值是否存在于给定的值列表中，其基本语法是在列名后跟IN关键字，再用圆括号包裹一组以逗号分隔的值。例如SELECT * FROM users WHERE country IN ('中国', '美国', '日本')，这条语句等价于三个OR条件的组合，但书写形式明显更紧凑。
IN的值列表支持多种数据类型。数值类型不需要加引号，例如WHERE id IN (1, 5, 9, 12)；字符串和日期类型需要用引号包裹，例如WHERE name IN ('Tom', 'Jerry')和WHERE create_date IN ('2024-01-01', '2024-06-01')。需要注意的是，值列表中的所有值类型应与列类型兼容，否则某些数据库会触发隐式类型转换，进而导致索引失效。
-- 查询部门编号为 10、20、30 的员工
SELECT emp_name, dept_no, salary
FROM employee
WHERE dept_no IN (10, 20, 30);
-- 查询状态为待支付或已取消的订单
SELECT order_id, status, amount
FROM orders
WHERE status IN ('PENDING', 'CANCELLED');
除了常量列表，IN最常见的进阶用法是配合子查询，把另一张表查询出的结果作为筛选条件。比如要查出所有下过订单的客户，可以这样写：
SELECT customer_id, customer_name
FROM customers
WHERE customer_id IN (
SELECT DISTINCT customer_id
FROM orders
WHERE order_date >= '2024-01-01'
);
这种写法比手工维护一份ID列表灵活得多，子查询会随着数据表的变化自动更新结果，避免了硬编码带来的同步问题。
二、IN与多重OR的区别：可读性、性能与索引
从语义上讲，WHERE col IN (a, b, c)与WHERE col = a OR col = b OR col = c在逻辑上完全等价，多数数据库返回的结果集也一致。但在工程实践中，两者的差异主要体现在三个方面。
第一是可读性和可维护性。IN把值集中放在一对圆括号内，结构清晰，后续增删值只需操作列表本身；而OR写法每个条件都要重复列名，值一多就容易写错，比如漏掉OR后面的列名，写成country='中国' OR '美国'这种永远为真或为假的条件，属于典型的高频错误。
第二是执行效率。现代优化器在多数场景下会把IN和OR优化成相同的执行计划，例如都转换为索引上的多次查找或范围扫描。但在部分数据库的老版本中，长串OR可能导致优化器放弃索引选择全表扫描，而IN列表会被改写为更高效的查找方式。因此普遍的建议是：值列表场景优先使用IN。
第三是索引利用上的细节。当IN列表非常长时（比如上千个值），无论写成IN还是OR，优化器都可能面临统计信息估算偏差的问题。此时更稳妥的做法是把值放入临时表或使用子查询关联，让优化器基于表统计信息做决策。
| 对比维度 | IN操作符 | 多重OR |
|---|---|---|
| 语法简洁度 | 值集中罗列，结构清晰 | 重复书写列名，冗长 |
| 维护成本 | 增删值只改列表 | 需逐条修改条件 |
| 出错概率 | 较低 | 易漏写列名或逻辑符号 |
| 配合子查询 | 原生支持 | 需改写为EXISTS等 |
三、NOT IN的陷阱与NULL值处理
IN有一个孪生兄弟NOT IN，用于筛选不在值列表中的记录。语法上完全对称，但NOT IN有一个著名的坑：如果值列表或子查询结果中包含NULL，整个NOT IN条件会对部分甚至全部记录返回UNKNOWN，导致查询结果莫名缺失。例如WHERE id NOT IN (1, 2, NULL)，任何值与NULL比较结果都是UNKNOWN，最终一条记录都查不出来。
-- 危险写法：子查询若返回NULL，结果集为空
SELECT * FROM products
WHERE category_id NOT IN (
SELECT category_id FROM disabled_categories
);
-- 安全写法：子查询中显式排除NULL
SELECT * FROM products
WHERE category_id NOT IN (
SELECT category_id FROM disabled_categories
WHERE category_id IS NOT NULL
);
规避这个坑的方法有两种：一是在子查询里加上IS NOT NULL过滤；二是改用NOT EXISTS，它对NULL免疫，语义也更明确。对于关联子查询场景，有经验的开发者通常直接选择EXISTS或NOT EXISTS，可读性和稳定性都更好。
四、大批量值列表的优化技巧
当IN列表中的值达到成百上千个时，会遇到两个现实问题：一是SQL语句长度可能超出数据库限制，二是优化器对超长列表的处理效率下降。以MySQL为例，虽然对IN列表的长度没有硬性上限，但过长的列表会拖慢解析阶段，也会让执行计划偏离最优路径。
常见的优化方案是分批查询：把大列表切成若干批次，在应用层汇总结果。例如每批500个值循环查询，配合已建好的索引，整体耗时往往比一次性传入上万值更低。另一种方案是把值插入临时表，再用JOIN替代IN：
-- 将大批量ID插入临时表后用JOIN关联 CREATE TEMPORARY TABLE tmp_ids (id INT PRIMARY KEY); INSERT INTO tmp_ids VALUES (101),(102),(103); -- 实际可批量插入 SELECT e.* FROM employee e JOIN tmp_ids t ON e.emp_id = t.id;
JOIN方案的好处是让优化器拿到真实的表统计信息，可以选择更优的连接顺序和访问路径。此外，如果值列表本身来自数据库中的另一张表，直接使用IN子查询或JOIN，避免把数据拉到应用层再传回去，能显著减少网络往返开销。
总结一下，IN操作符是SQL中处理多值匹配的首选方式，它语法简洁、易于维护，在绝大多数场景下与多重OR等价甚至更优。使用时注意值类型与列类型匹配、NOT IN的NULL陷阱，以及超长列表的分批或JOIN优化，就能写出既清晰又高效的查询语句。