更新null字段本身不会导致索引失效；真正影响索引使用的是where条件中is null等查询逻辑及字段是否允许null。
更新 NULL 字段本身不会导致索引失效；真正影响索引使用的是 WHERE 条件中出现 IS NULL 或涉及 NULL 的查询逻辑，以及字段定义是否允许 NULL。
UPDATE 语句里 SET col = ... 不会“让索引失效”
执行 UPDATE t SET col = 0 WHERE id = 123; 这类操作，只要 WHERE 条件能走索引（比如用到了主键或 id 上的索引），更新过程就照常利用索引定位行，然后修改数据页和对应索引项。NULL 值被更新为非 NULL，只是普通的数据变更，B+ 树索引会正常维护——不触发“失效”。
常见误解来源：有人看到 EXPLAIN 对 SELECT ... WHERE col IS NULL 显示 key=NULL，就误以为“这个字段有 NULL，所以整个索引坏了”，其实失效只发生在特定查询条件上，不是持久性状态。
真正出问题的是 WHERE col IS NULL 这类查询条件
当你要查“哪些行是 NULL”，MySQL 面临两个硬约束：
- InnoDB 的 B+Tree 索引默认不把
NULL当作可排序、可比较的常规值写入键值序列，它被单独管理（例如放在叶子页最左） - 优化器估算成本时，发现该列 NULL 占比高（比如 >20%），全表扫描反而比遍历索引再回表更快，于是跳过索引
结果就是：EXPLAIN SELECT * FROM t WHERE col IS NULL; 返回 type=ALL、key=NULL——这不是索引不能用，而是优化器主动放弃。
验证方法：
- 运行
SHOW INDEX FROM t WHERE Key_name = 'idx_col';，确认Null列值为YES - 强制走索引：
EXPLAIN SELECT * FROM t FORCE INDEX (idx_col) WHERE col IS NULL;，对比rows是否显著下降 - 更新统计：
ANALYZE TABLE t;，避免旧统计误导优化器
联合索引中 UPDATE NULL 列可能间接破坏最左前缀匹配
比如有联合索引 (a, b)，你执行：
UPDATE t SET a = NULL WHERE b = 1;
之后再查 WHERE a IS NULL AND b = 1，这个查询大概率不走 (a,b) 索引。原因不是 UPDATE 导致索引损坏，而是：
-
a IS NULL无法提供确定的 B+Tree 查找起点（NULL 不参与排序） - 最左前缀中断 → 后续
b = 1的有序性无法利用 - 同理，
WHERE a IS NULL OR b = 1基本放弃索引，OR 加 IS NULL 是双重打击
注意：如果改成 WHERE a = 1 AND b IS NULL，则能走索引——a = 1 定位子树后，在子树内线性扫描 b IS NULL，仍算有效利用。
UNIQUE 索引上 IS NULL 查询最难优化
因为 SQL 标准允许 UNIQUE 索引中存在任意多个 NULL（它们彼此不冲突），优化器无法假设 WHERE col IS NULL 结果集很小。哪怕表里只有一行 NULL，它也按“可能有成百上千个”的悲观估计算成本，最终倾向全表扫描。
这种场景下，改字段为 NOT NULL DEFAULT 0 是根治办法。但要注意：
- 存量数据需清洗：
SELECT COUNT(*) FROM t WHERE col IS NULL;非零就得先处理 - 应用层 ORM 可能默认映射为可空类型（如 Java 的
Integer），需同步调整为基本类型或显式判空 - 日志类字段（如
processed_at）若天然大量未处理，强制设默认值会污染语义，此时更适合加生成列索引，比如processed_at_is_null TINYINT GENERATED ALWAYS AS (IF(processed_at IS NULL, 1, 0)) STORED，再建索引
最易被忽略的一点：函数索引（如 COALESCE(col, -1)）在 MySQL 8.0.13+ 能绕开部分问题，但它要求业务层所有写入都统一用该逻辑标记，否则 NULL 还是原样落库，索引照样“看不见”。
