怎么利用 SQL 的 IN 运算符简化多条件的 OR 连接查询逻辑

说到SQL查询优化，IN运算符绝对是个好用的小工具——它能帮你把一堆OR条件浓缩成一行，代码看起来清爽，维护起来也省心。更重要的是，它还能配合子查询动态生成条件集，顺手规避SQL注入风险。当然，也有一些边界情况需要注意，比如NULL值的处理和索引优化，尤其是NOT IN配合子查询时容易踩坑。下面逐一拆解。

IN 直接替代重复的列 = 值 OR 列 = 值

当查询需要匹配同一列的多个离散值时，IN就是最直接、最自然的替代方案。来看个例子：

SELECT * FROM users WHERE status = 'active' OR status = 'pending' OR status = 'trial';

改成IN版本：

SELECT * FROM users WHERE status IN ('active', 'pending', 'trial');

两者逻辑完全一样，但后者一眼就能看明白，以后要增删条件，直接改括号里的列表就行，省事多了。

支持子查询，动态生成条件集合

IN还能配合子查询使用，把“先查出哪些ID符合规则，再用这些ID去查主表”这两步合并成一步，省去临时表或多次查询的麻烦。比如查所有下过订单且订单总金额超过500的客户信息：

SELECT * FROM customers WHERE id IN (
  SELECT customer_id FROM orders 
  GROUP BY customer_id 
  HA VING SUM(amount) > 500
);

这比先查出ID列表再在应用层拼字符串安全得多，既避免了SQL注入风险，又省了一次网络交互。

注意 NULL 和性能的边界情况

有一点需要特别留意：IN对NULL值不太友好。如果右边的列表里混进了NULL，比如 WHERE col IN (1, 2, NULL)，这条条件会直接变成UNKNOWN，不会匹配任何行。这不是bug，而是SQL三值逻辑的固有特性。如果你的业务场景需要包含NULL，记得显式加上 OR col IS NULL。

再说性能：值列表不长（比如几十个以内）时，IN和等价的OR链性能差别不大。但如果值太多（上千个），某些数据库可能优化不好，这时候考虑用临时表加JOIN更稳妥。当然，前提是被查字段有索引，IN才能利用索引快速定位，否则还是得全表扫。

与 NOT IN 要小心子查询返回 NULL

NOT IN有个容易踩的坑——如果子查询返回了NULL，整个条件就会返回空结果集。因为 value != NULL 永远为UNKNOWN。比如这个查询：

SELECT name FROM employees WHERE dept_id NOT IN (
  SELECT dept_id FROM departments WHERE region = 'CN'
);

如果子查询中某行的dept_id是NULL，那整条语句就查不到任何员工——即使其他dept_id完全匹配。稳妥的做法是给子查询加个过滤：

WHERE dept_id NOT IN (
  SELECT dept_id FROM departments WHERE region = 'CN' AND dept_id IS NOT NULL
);

或者干脆改用 NOT EXISTS，它天然规避NULL陷阱，写法也更贴近语义。