MySQL索引对IS NULL查询不友好，因B-tree默认不将NULL视为有效键值存储，无法参与排序与快速查找，导致大多情况全表扫描；例外是高NULL比例时优化器可能主动放弃索引。
MySQL索引为什么对IS NULL查询不友好
B-tree索引默认不把NULL当作有效键值存储，所以即使你在status列上建了普通索引，执行WHERE status IS NULL时，MySQL大概率会放弃走索引，转为全表扫描或全索引扫描。
这不是bug，是B-tree结构的天然限制：NULL没有确定的排序位置，无法参与范围比较和等值查找的快速跳转。InnoDB虽然允许索引列含NULL，但实际构建索引树时会跳过这些行（或仅用特殊标记占位），导致IS NULL无法利用B-tree的二分查找优势。
- 验证方式：用
EXPLAIN看type是否为ALL或index，key是否为空 - 例外情况：如果该列几乎全是NULL（比如95%+），优化器可能认为走索引反而更慢，主动选择全表扫描——这时强制
USE INDEX也无济于事 - 替代方案：建函数索引（MySQL 8.0.13+）
CREATE INDEX idx_status_null ON t ( (status IS NULL) )，把布尔结果作为索引键
COUNT(column)与COUNT(*)在NULL存在时行为差异
COUNT(column)只统计非NULL值，COUNT(*)统计所有行——这个区别在聚合逻辑中极易被忽略，尤其当字段允许NULL且业务语义要求“计数全部记录”时。
比如订单表amount字段允许NULL（表示金额未确认），用COUNT(amount)算“已确认订单数”是对的；但若想算“总订单数”，就必须用COUNT(*)，否则漏掉NULL行会导致报表少算。
-
SUM()、AVG()、MAX()、MIN()同样跳过NULL，无需额外处理 - 想把NULL当0参与计算？用
COALESCE(amount, 0)包裹，但注意AVG(COALESCE(amount, 0))和AVG(amount)物理意义完全不同 - 前端展示常需“空值显示为0”，但数据库层不该盲目
COALESCE——聚合口径必须和业务定义严格对齐
用NOT IN查数据突然变空，大概率是NULL在作祟
NOT IN子查询里只要出现一个NULL，整个条件就变成UNKNOWN，WHERE直接过滤掉所有行——这不是性能问题，是逻辑崩塌。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
例如：SELECT * FROM orders WHERE user_id NOT IN (SELECT user_id FROM users WHERE status = 'inactive')，一旦子查询返回任意user_id IS NULL，结果必为空。
- 根本原因：SQL三值逻辑，
NOT IN展开为多个!=的AND组合，任一!= NULL即得UNKNOWN - 安全写法：子查询加
WHERE user_id IS NOT NULL，或改用NOT EXISTS（它天然规避NULL传染） - 更稳方案：把NULL显式转为哨兵值（如-1），并在应用层约定该值代表“未知”，但需同步修改索引和查询逻辑
设计阶段就该堵住NULL滥用的源头
允许NULL的列，每多一个，就多一层隐式成本：额外1位NULL位图空间、索引选择性下降、查询条件必须显式处理、ORM映射易出空指针、报表逻辑反复打补丁。
真正需要“未知”语义的场景极少。多数时候，0（数字）、''（字符串）、'1970-01-01'（日期）比NULL更可控，且能走索引、可比较、不触发三值逻辑。
- 迁移存量NULL字段：先加
NOT NULL约束并设默认值，再批量UPDATE ... SET col = COALESCE(col, 0) - JSON字段除外：MySQL对JSON类型中的NULL有独立处理逻辑，但这是另一套体系，不适用于原子列
- 唯一索引慎用NULL：InnoDB允许多行NULL共存（因NULL不参与唯一性校验），这常导致误以为“去重生效”，实则埋雷
NULL不是语法糖，是语义开关。它一旦打开，所有基于确定性假设的优化（索引、聚合、连接、子查询）都得重新评估逻辑边界。最省事的处理方式，是在CREATE TABLE时就写死NOT NULL。
