MySQL 三值逻辑排查：NULL、UNKNOWN 与 WHERE 条件的误判边界

线上订单列表突然从几十毫秒涨到几百毫秒，第一眼看 SQL 往往是 WHERE shipped_at IS NULL：字段明明建了索引，为什么还会慢？关键不在于 NULL 能不能进 B+Tree，而在于条件选择性、复合索引顺序和回表成本是否值得。

下面用一张订单表复现这个判断。示例数据只用于观察执行计划，生产环境应在同版本、同数据分布的副本上验证。

先确认 NULL 真的进入了索引范围

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  buyer_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  shipped_at DATETIME NULL,
  status VARCHAR(16) NOT NULL,
  KEY idx_shipped_at (shipped_at),
  KEY idx_buyer_ship (buyer_id, shipped_at)
);

EXPLAIN SELECT id, buyer_id, created_at
FROM orders
WHERE shipped_at IS NULL;

常规 B+Tree 索引会把 NULL 当作可排序的索引值，因此优化器可以把 IS NULL 转成索引范围。执行计划里的 type=ref、range 或者较小的 rows，通常说明索引路径被考虑了；但最终是否采用，还要看统计信息和预计回表数量。

为什么有索引仍可能被优化器放弃

假设表里 90% 的订单仍未发货，shipped_at IS NULL 的选择性就很低。即使索引能找到这些 NULL 记录，随后还要按主键回表读取 buyer_id 和 created_at。大量随机回表可能比顺序扫表更贵，所以执行计划选择 type=ALL 并不代表索引损坏。

排查时把估算和实际分开看：

如果数据分布刚发生过大变化，先执行 ANALYZE TABLE orders 更新统计信息，再用 EXPLAIN ANALYZE 对比估算行数与实际行数。不要直接用 FORCE INDEX 掩盖错误统计。

复合条件下，索引顺序决定能否提前缩小范围

真实列表通常还会按买家过滤：

SELECT id, buyer_id, created_at
FROM orders
WHERE buyer_id = 2088
  AND shipped_at IS NULL
ORDER BY created_at DESC
LIMIT 20;

idx_buyer_ship (buyer_id, shipped_at) 先按等值条件锁定买家，再在该买家的 NULL 范围内查找，通常比单列 idx_shipped_at 更稳。若排序仍是热点，可按真实查询形态评估 (buyer_id, shipped_at, created_at)，但要注意索引变宽后的写入和缓存成本。

反过来，如果查询只有 WHERE shipped_at IS NULL，索引 (buyer_id, shipped_at) 不能跳过左侧的 buyer_id 直接高效定位。复合索引不是列的集合，而是一条有顺序的查找路径。

三种改法怎么选

• 结果很少、列也少：保留单列或复合索引，优先让查询走覆盖索引，减少回表。
• NULL 占比很高：增加更有区分度的等值条件，或把“未发货”建模为稳定状态列，再用状态与时间组合索引。
• 历史数据极大：先确认查询是否只读近期订单；用时间范围缩小扫描比继续堆单列索引更可靠。

状态列也不是万能替代。若业务允许“未发货”和“未知”两种语义，不能为了索引把 NULL 粗暴改成空字符串；数据语义、写入规则和查询条件必须一起迁移。

用一轮可重复检查收尾

ANALYZE TABLE orders;
EXPLAIN ANALYZE
SELECT id, buyer_id, created_at
FROM orders
WHERE buyer_id = 2088 AND shipped_at IS NULL
ORDER BY created_at DESC LIMIT 20;

把执行计划保存下来，重点对比实际读取行数、返回行数、是否发生 filesort，以及改索引前后的写入延迟。若实际行数远高于估算值，优先修统计信息或数据分布问题；若只差在回表，才值得评估覆盖索引。

常见问题

MySQL 的普通索引会忽略 NULL 吗？

不会。InnoDB 普通 B+Tree 索引可以存储 NULL，IS NULL 有机会使用索引，但最终计划仍由选择性和成本估算决定。

为什么加了 FORCE INDEX 反而更慢？

因为强制索引跳过了优化器的成本判断。低选择性条件下，大量回表可能比全表顺序读取更贵。

把 NULL 改成空字符串会更快吗？

不一定，而且会改变语义。只有在业务明确不需要三值逻辑时，才考虑状态列或默认值，并重新设计索引。

复合索引一定要把 NULL 列放最后吗？

没有固定答案。先放能稳定缩小范围的等值条件，再结合排序和范围条件验证；最终以目标查询的执行计划和写入成本为准。