in是最直接的集合匹配方式，用于判断字段值是否属于指定离散值集合，本质是多个=条件的简写；不支持动态集合生成（除子查询外），不等价于between或like，需注意null处理、类型一致、索引使用及元素数量限制。
WHERE column IN (...) 是最直接的集合匹配方式
MySQL 中 IN 用于判断某字段值是否属于指定的离散值集合，本质是多个 = 条件的简写。它不支持子查询以外的动态集合生成，也不等价于范围查询（BETWEEN）或模糊匹配（LIKE）。
常见错误是把字符串拼成单个值传入，比如写成 WHERE id IN ('1,2,3') —— 这实际只匹配字符串 '1,2,3'，不是三个数字。
- 正确写法必须显式列出每个字面量：
WHERE status IN ('active', 'pending') - 值类型需一致：字符串加引号，数字不加；混合类型可能触发隐式转换，导致索引失效
- 最多支持约 1000 个元素（受
max_allowed_packet和优化器限制），超量建议改用临时表或JOIN
IN 配合子查询实现动态集合过滤
当集合来自另一张表或计算结果时，必须用子查询。注意子查询只能返回单列，且最好有索引支撑，否则性能急剧下降。
典型场景：查所有下过订单的用户信息。
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE created_at > '2024-01-01');
- 子查询若返回
NULL，整行会被跳过（IN对NULL永远返回UNKNOWN） - 等价写法是
EXISTS，在子查询结果集大、主表小时通常更快 - MySQL 8.0+ 支持
IN子查询自动去重，但旧版本需手动加DISTINCT
IN 和 NOT IN 的 NULL 行为差异很大
NOT IN 遇到子查询含 NULL 时，结果恒为空——这是最容易踩的坑。因为 value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而 value != NULL 永远为 UNKNOWN，整个条件不成立。
- 安全替代方案：
NOT EXISTS或LEFT JOIN ... IS NULL - 若坚持用
NOT IN，务必排除NULL：WHERE id NOT IN (SELECT id FROM t2 WHERE id IS NOT NULL) - 检查子查询是否可能返回
NULL，尤其是涉及外连接或可空字段时
IN 在索引使用和执行计划中的表现
MySQL 能对 IN 列使用索引，但仅限于「单列索引」且「值数量不多」时走 range 访问类型。一旦值过多或数据分布倾斜，优化器可能放弃索引，改用全表扫描。
- 用
EXPLAIN观察type是否为range，key是否命中预期索引 - 复合索引中，
IN只能用到最左前缀的连续部分；例如索引(a,b,c)，WHERE a IN (1,2) AND b = 3可用前两列，但WHERE b IN (1,2)无法使用该索引 - 大量离散值（如 5000 个 ID）建议改用临时表 +
JOIN，避免解析和优化开销
实际业务里，IN 看似简单，但子查询的 NULL 处理、索引能否生效、值列表长度边界，这三点出问题的概率远高于语法错误。
