优先用 not in（小列表）、not exists（子查询含 null 时）或临时表 join（大列表），避免手动拼 、慎防 not in 遇 null 返回空结果。
用 NOT IN 排除固定 ID 列表最直接
当你要从表里剔除几个明确知道的 id 值时，NOT IN 是最直觉的写法。比如想查出除了 101、205、317 之外的所有用户：
SELECT * FROM users WHERE id NOT IN (101, 205, 317);
注意三点：一是括号内必须是常量或子查询结果；二是所有值类型要和 id 字段一致（比如 id 是整数，就别混进字符串 '101'）；三是如果列表里有 NULL，整个 NOT IN 会返回空结果——这是 SQL 三值逻辑导致的常见陷阱。
IN 列表太长时改用临时表或 JOIN
当要排除的 ID 有几百上千个，硬写进 NOT IN 不但难维护，还可能触发某些数据库的参数限制（比如 MySQL 的 max_allowed_packet 或 PostgreSQL 的绑定变量上限）。这时更稳的方式是把 ID 列表转成一张临时表再左连接过滤：
SELECT u.* FROM users u LEFT JOIN exclude_ids e ON u.id = e.id WHERE e.id IS NULL;
其中 exclude_ids 可以是真实临时表、CTE（WITH exclude_ids AS (...) SELECT ...），或者应用层传入的内存表（如 PostgreSQL 的 UNNEST(ARRAY[...])）。这种方式还能走索引，比超长 NOT IN 更快。
用 NOT EXISTS 替代 NOT IN 避开 NULL 问题
如果你的排除列表来自子查询，且该子查询可能返回 NULL（比如关联字段允许为空），NOT IN 就会静默失效。此时必须换用 NOT EXISTS：
SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM banned_users b WHERE b.user_id = u.id );
它不依赖值比较，而是检查是否存在匹配行，天然绕过 NULL 导致的逻辑中断。性能上，只要 banned_users.user_id 有索引，通常比 NOT IN 子查询更可靠。
WHERE id 所有值？别这么干
有人试图用一堆 AND id 101 AND id 205 拼条件来替代 NOT IN，这在 ID 数量少时看似可行，但很快会失控。不仅写起来累，而且数据库优化器很难对大量离散等值否定条件做有效索引选择，执行计划容易退化为全表扫描。更关键的是，这种写法无法参数化，几乎没法安全地交给 ORM 或预编译语句处理。
真正需要动态排除时，优先走 NOT IN（小列表）、NOT EXISTS（子查询场景）或显式构造临时数据集（大列表），而不是手动拼 。
