NOT IN 查询慢是因为遇 NULL 返回 UNKNOWN 导致结果为空且优化器放弃索引下推，易退化为全表扫描；应改用 LEFT JOIN + IS NULL 或 NOT EXISTS，并确保连接字段非空、有索引，子查询条件移至 ON 子句。
MySQL 中 NOT IN 查询慢，不是“写法不够优雅”的问题，而是它在多数真实场景下会直接触发全表扫描、忽略索引、且对 NULL 敏感到语义失效——查不出数据还巨慢，是常态，不是例外。
为什么 NOT IN 会让 EXPLAIN 显示 type: ALL
核心在于 MySQL 优化器面对 NOT IN (subquery) 时几乎无法做索引下推。哪怕左表、右表字段都有索引，只要子查询里可能含 NULL（比如没加 WHERE col IS NOT NULL），整个条件就变成 UNKNOWN，优化器只能放弃走索引，退化为嵌套循环 + 全表扫描。
-
EXPLAIN中key为NULL、rows等于主表总行数、Extra出现Using where; Using join buffer，就是典型信号 - 子查询带过滤条件（如
WHERE status = 'banned'）时，NOT IN无法把该条件“下推”进右表扫描，只能先取全量再逐行比对 - 即使子查询结果只有几十行，只要没显式排除
NULL，逻辑就已不可靠；一旦结果变大（比如几千行），性能断崖式下跌
LEFT JOIN + IS NULL 的硬性前提
这不是语法替换，而是语义重写。改错一步，结果就错或更慢。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 连接字段必须严格等值：
ON a.id = b.id，不能是ON a.id = CAST(b.id AS SIGNED)或函数包装 - 右表连接字段（如
b.id）**必须非空**：建表时加NOT NULL最好；若不能改结构，子查询中必须加WHERE b.id IS NOT NULL - 原
NOT IN子查询里的过滤条件（如status = 'inactive'）**必须写进ON，不能放WHERE**，否则外连接变内连接，漏数据 -
WHERE中判断的是右表别名字段是否为NULL，例如WHERE b.id IS NULL，写成WHERE a.id IS NULL完全错误
NOT EXISTS 更适合哪些场景
当右表数据量大、连接字段重复多、或本身含大量 NULL 时，NOT EXISTS 往往比 LEFT JOIN 更稳。
-
NOT EXISTS天然规避NULL语义陷阱：子查询返回空集即为TRUE，不依赖右表字段是否为NULL - 执行计划通常显示为
DEPENDENT SUBQUERY，IO 更少，尤其适合右表有复合索引（如(id, status)）的场景 - 示例写法：
SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'inactive') - 注意：
SELECT 1是惯例，写SELECT *无意义且可能被误优化；右表关联字段上仍需有索引
容易被忽略的细节：字符集与隐式转换
即使语法全对、索引也建了，LEFT JOIN 或 NOT EXISTS 仍可能不走索引——大概率是类型或字符集不一致导致隐式转换。
- 检查
EXPLAIN的key_len：如果远小于字段定义长度（比如VARCHAR(50)字段索引只用了 2 字节），说明发生了截断或转换 - 左右表连接字段必须字符集完全一致，比如都是
utf8mb4_0900_as_cs；混用utf8mb4_general_ci和utf8mb4_0900_as_cs会导致索引失效 -
VARCHAR对CHAR、BIGINT对INT、带符号对无符号，都会触发隐式转换，EXPLAIN中Type可能降级为ALL或range
重构不是换一个关键词，而是重新理解“差集”在 MySQL 中如何被安全、高效地表达。最危险的，是改完后没跑 EXPLAIN 验证 key 和 rows，或者没确认右表数据里到底有没有 NULL。
