NOT IN 遇到 NULL 会因三值逻辑返回 UNKNOWN 导致结果为空，是 SQL 标准行为；应改用 NOT EXISTS 或 LEFT JOIN + IS NULL，并确保关联字段非空、类型一致、条件位置正确。
NOT IN 遇到子查询或列表中任意一个 NULL，整个条件就求值为 UNKNOWN，而 WHERE 只保留 TRUE 行，结果必然为空——这不是 MySQL 的 bug，是 SQL 标准三值逻辑的必然行为。
NOT IN 实际展开成一串 AND 判断，!= NULL 永远是 UNKNOWN
当你写 WHERE id NOT IN (SELECT user_id FROM orders)，MySQL（和其他主流数据库）内部会把它等价展开为：
id != value1 AND id != value2 AND id != value3 AND ... AND id != NULL
而 SQL 规定：任何值与 NULL 做比较（=、!=、、> 等）结果都是 UNKNOWN。只要 AND 表达式中有一个 UNKNOWN，整个表达式就是 UNKNOWN。
-
WHERE子句只接受TRUE的行，UNKNOWN和FALSE都被过滤掉 - 哪怕子查询只返回一个
NULL，比如SELECT user_id FROM orders查出(1, 2, NULL)，整张主表就查不到任何记录 - 手动执行子查询能看到数据，但一塞进
NOT IN就“静默失效”，这是最典型的误判信号
为什么加了索引也查不出数据？优化器不敢下推
不是索引没建好，而是优化器主动放弃使用它——因为 NULL 让语义变得不确定。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
EXPLAIN中常见type: ALL、key_len: NULL、Extra: Using where; Using join buffer - 即使右表字段有索引，且你确认它非空，MySQL 5.6 或更低版本几乎从不走索引；5.7+ 在含
NULL或复杂条件时仍大概率退化 - 字符集或类型不一致（如
VARCHAR(20)vsVARCHAR(50)）会触发隐式转换，进一步让索引失效 - 优化器宁可全表扫描，也不愿在无法保证语义安全的前提下做索引下推
NOT EXISTS 是最直接可靠的替代方案
它不比值，只判“是否存在匹配行”，天然绕过 NULL 干扰，且语义更贴近“差集”本意。
- 必须写成相关子查询：
NOT EXISTS (SELECT 1 FROM banned_users b WHERE b.user_id = u.id)，漏掉b.user_id = u.id就变成常量子查询，逻辑全错 - 子查询里用
SELECT 1，别写SELECT *或具体字段 - 原
NOT IN子查询中的过滤条件（如status = 'inactive'）必须平移进子查询的WHERE，不能留在外层 - 关联字段类型要一致，否则隐式转换会让索引失效（比如一边是
INT，一边是VARCHAR）
LEFT JOIN + IS NULL 写错一步就翻车
它语义直观，但容错率极低，常见错误比想象中多。
-
ON条件只能是严格等值：o.customer_id = c.id，不能加COALESCE、CAST或函数 - 右表连接字段若允许
NULL，必须在ON中显式排除：AND c.id IS NOT NULL，否则仍可能引入UNKNOWN - 子查询里的过滤条件（如
status = 'active'）必须挪进ON，写在最后的WHERE会让LEFT JOIN变成INNER JOIN -
WHERE里只能写c.id IS NULL，c.id = NULL永远不成立 - 一对多关系下会产生重复行，需额外加
DISTINCT或GROUP BY，否则数据量会膨胀
真正容易被忽略的是：即使你确认子查询不含 NULL，只要字段定义允许 NULL 且没加 NOT NULL 约束，优化器仍可能保守处理；而线上数据质量波动（比如某天同步脚本写入了 NULL）会让原本正常的 NOT IN 突然失效——这种问题往往深夜报警才暴露。
