in是替代多个or的等价写法，需确保类型对齐、数量合理、null处理得当；字符串字段值须加单引号，整数字段不可加；值过多导致索引失效，建议≤1000；not in遇null恒为unknown，应改用not exists；多列in需括号匹配且依赖联合索引。
IN 不是用来“简化语法”的装饰品，而是直接替代多个 OR 的等价写法，语义清晰、执行计划更可控——但前提是值类型对齐、数量合理、NULL 处理得当。
IN 里数字和字符串怎么加引号？类型不一致会出什么错
左侧字段是 INT 类型（如 id），右侧值就不能加引号：WHERE id IN (1, 2, 3) 是对的；WHERE id IN ('1', '2', '3') 在 MySQL 中可能隐式转换成功，但在 PostgreSQL 或严格模式下直接报错：operator does not exist: integer = text。
- 字符串字段（如
status、name）必须每个值都用单引号包裹：WHERE status IN ('active', 'pending') -
IN左右类型必须严格一致：不能混用'1'和2，也不能在整数列表里塞NULL - MySQL 虽允许隐式转换，但会导致索引失效（比如对
id字段加了索引，但写成IN ('1', '2')后走全表扫描）
IN 值太多（几千个）时为什么变慢？怎么办
不是“慢”，而是执行计划可能退化：IN 列表过长会让优化器放弃使用索引，转为全表扫描；同时解析、传输、缓存也压力增大。MySQL 没硬限制，但实际建议控制在 1000 以内。
- 超过几百项就该警惕：用
EXPLAIN看type是否还是range，key是否命中索引 - 值来自应用层（比如前端传来的 ID 列表），优先拆成多批次查询，每批 ≤ 500 项
- 值来自另一张表，别用
WHERE x IN (SELECT y FROM t)，改用JOIN：SELECT u.* FROM users u JOIN active_users a ON u.id = a.id - 真要处理上万 ID，建临时表插入再
JOIN，比超长IN更稳
NOT IN 为什么查不到数据？NULL 是隐形杀手
NOT IN (1, 2, NULL) 不等于 “排除 1 和 2”，而是恒为 UNKNOWN，结果集为空——因为 id != NULL 永远不成立，整个布尔表达式坍缩。
- 子查询返回结果含
NULL（比如SELECT manager_id FROM employees可能有空值），NOT IN就失效 - 安全写法只有两种：
NOT EXISTS（推荐），或确保子查询过滤掉NULL：WHERE id NOT IN (SELECT id FROM t WHERE id IS NOT NULL) - 哪怕你确认列表里没
NULL，只要子查询逻辑可能产出NULL，就得提前防御
多列 IN 怎么写？(a,b) IN ((1,'x'), (2,'y')) 有用吗
有用，但只在匹配联合条件时才真正省事，比如查“指定用户在指定时间范围内的订单”。它不是语法糖，是语义等价于多个 AND+OR 的压缩写法。
- 必须用括号包住左侧字段：
WHERE (user_id, status) IN ((101, 'paid'), (102, 'shipped')) - 右侧每组值顺序、类型、数量必须和左边完全一致；少一个或类型错，直接报错
- 有联合索引
(user_id, status)时，这个查询能高效走索引；单列索引则大概率失效 - 值组超过 100 组后，同样面临解析开销和执行计划不稳定问题，别硬塞几千组
真正麻烦的从来不是怎么写 IN，而是写完之后没验证类型、没看执行计划、没防 NULL、没控数量——这些点漏一个，线上就可能慢三秒或查不出数据。
