IN用于精确匹配离散值，不能做模糊查询；常见错误包括误用作字符串包含、忽略NULL导致NOT IN失效、列表过长影响性能；正确场景是字段值等于括号内任一明确值。
IN操作符的基本用法和常见错误
IN 用于判断某字段是否等于括号内任意一个值，本质是多个 = 的简写。但新手常误以为它能做模糊匹配或字符串包含——比如想查 name 包含“张”或“李”，却写成 WHERE name IN ('张', '李')，这实际查的是**完全等于**“张”或“李”的记录，不是“包含”。
正确场景是：你有一组明确的离散值，且要精确匹配其中任一。例如查订单状态为 'pending'、'shipped' 或 'delivered' 的数据：
SELECT * FROM orders WHERE status IN ('pending', 'shipped', 'delivered');
- 括号内值类型必须与字段一致（字符串加引号，数字不加）
- 空值
NULL不能用IN判断，col IN (1, 2, NULL)永远返回FALSE或UNKNOWN，要用IS NULL单独处理 - 列表过长（如上千项）可能触发数据库限制，MySQL 默认
max_allowed_packet或执行计划退化
当“包含”指子字符串时，别硬套IN
如果真实需求是“字段值中包含指定关键词”，比如查用户名含“admin”或“test”的用户，IN 完全不适用。此时该用 LIKE 配合 OR，或更清晰的 REGEXP（MySQL）/ ~（PostgreSQL）：
SELECT * FROM users WHERE username LIKE '%admin%' OR username LIKE '%test%';
-
LIKE '%xxx%'无法走索引前缀，大数据量时性能差；若只查“开头包含”，用LIKE 'xxx%'可利用索引 - 多个
LIKE用OR连接，比嵌套CASE WHEN更直观；但超过 5–6 个条件时，考虑应用层拆分或全文索引 - 注意通配符转义：若关键词本身含
%或_，需用ESCAPE子句，例如LIKE '%100\%' ESCAPE '\'
IN和NOT IN在空值下的陷阱
NOT IN 是高频翻车点。只要子查询或列表中存在 NULL，整个条件直接失效——因为 value != NULL 永远为 UNKNOWN，而 WHERE 只接受 TRUE。
例如：SELECT name FROM users WHERE id NOT IN (1, 2, NULL); 不会返回任何结果，哪怕有 id=3 的用户。
- 安全做法：显式排除空值，
WHERE id NOT IN (SELECT id FROM blacklist WHERE id IS NOT NULL) - 更推荐改用
NOT EXISTS，它对空值天然鲁棒：WHERE NOT EXISTS (SELECT 1 FROM blacklist b WHERE b.id = users.id) - PostgreSQL 支持
NOT IN (...) IS NOT TRUE作为临时绕过，但可读性差，不建议
大列表IN查询的性能优化思路
当需要匹配几百甚至几千个 ID（比如导出指定用户的订单），直接拼长 IN 列表会导致 SQL 过长、解析慢、执行计划不准。
- 优先走临时表：把 ID 列表写入临时表，用
JOIN替代IN，数据库能更好估算行数 - 分批次执行：应用层切分成每 500 个一组，循环查询，避免单次超长 SQL 和连接超时
- MySQL 8.0+ 可用
VALUES ROW构造虚拟表：SELECT * FROM orders JOIN (VALUES ROW(1), ROW(2), ... ) AS v(id) ON orders.user_id = v.id; - 确认字段有索引——
IN能用上索引的前提是字段已建索引，且查询值类型与索引列一致（比如索引是INT，传字符串会隐式转换导致索引失效）
真正难的不是写对语法，而是分清“集合成员判断”和“字符串模式匹配”这两类问题——前者用 IN，后者绕不开 LIKE 或正则，混用只会让逻辑和性能同时失控。
