IS NULL 查询慢因B-tree索引不存NULL值，常致全表扫描；单列独立索引可走ref_or_null，联合索引中IS NULL易使后续列失效；多列IS NULL几乎必退化为全表扫描；优化宜用默认值替代或冗余计算列索引。
IS NULL 查询为什么慢得离谱
因为 MySQL 的 B-tree 索引默认不存储 NULL 值，WHERE column IS NULL 无法像 = 那样走高效索引查找。优化器往往被迫退化为全表扫描，尤其当该列 NULL 比例高、又没索引时，EXPLAIN 里会看到 type = ALL 和 rows 接近表总行数。
更隐蔽的坑是：联合索引中哪怕只有一列参与 IS NULL，也可能让整个索引失效——比如 idx_a_b_c(a,b,c)，查询 WHERE a = 1 AND b IS NULL，c 就再也用不上了。
单字段 IS NULL 还能用索引，但有前提
MySQL 支持 ref_or_null 访问类型，它能把 “等于某个值” 和 “是 NULL” 合并成一次索引扫描。但这只对单个索引列生效，且要求该列必须是独立索引（不是联合索引的非首列）。
- ✅ 有效：给
status单独建索引INDEX idx_status(status)，然后查WHERE status IS NULL或WHERE status = 'draft' OR status IS NULL - ❌ 无效：在联合索引
idx_user_status(user_id, status)上查WHERE user_id = 123 AND status IS NULL，status IS NULL部分大概率被下推到 server 层过滤，索引只用了user_id - ⚠️ 注意：
NOT NULL列上写IS NULL会被优化器直接剪枝，查询返回空结果集，不扫表但也没意义
多字段同时 IS NULL 是性能黑洞
实测显示：两个字段都带 IS NULL 条件（如 WHERE a IS NULL AND b IS NULL），即使都有单列索引，MySQL 也几乎必然放弃索引合并，转为全表扫描或仅用其中一个索引再回表过滤——81 秒 vs 0.01 秒的差距就来自这里。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
根本原因是 ref_or_null 不支持跨列协同，优化器没有能力为多个 IS NULL 字段生成高效执行计划。
- 别指望加联合索引能救：联合索引
idx_a_b(a,b)对a IS NULL AND b IS NULL几乎无用 - 替代方案优先考虑用默认值：把业务上可接受的
NULL替换为0、'N/A'等具体值，查询改写为WHERE a = 0 AND b = 0，立刻回归普通等值查询路径 - 如果必须保留
NULL语义，可建冗余计算列并索引：例如ALTER TABLE t ADD COLUMN is_a_null TINYINT GENERATED ALWAYS AS (a IS NULL) STORED，再建索引INDEX idx_is_a_null(is_a_null)，但要注意写入开销
EXPLAIN 是唯一可信的判断依据
所有“应该能走索引”的直觉，在真实数据分布和查询条件下都可能翻车。每次改写含 IS NULL 的查询，必须跑 EXPLAIN FORMAT=TRADITIONAL 看三件事：
-
key是否非NULL（用了哪个索引） -
type是否为ref或ref_or_null（不是ALL或index） -
rows是否显著小于表总行数（比如 350 万行的表，rows是 2000 而不是 349 万）
特别警惕 Extra 列出现 Using where; Using index condition —— 这说明索引只做了初步过滤，大量行仍需回表后由 server 层二次判断 IS NULL，性能天花板很低。
