能建普通索引，但IS NOT NULL基本不走索引，UNIQUE索引更适合“应唯一但允许缺失”的场景，联合索引中空值字段应靠右或剔除，生成列是绕过空值干扰的有效方案。
空值字段能建普通索引吗？能，但效果打折
可以建，INDEX 和 UNIQUE INDEX 都允许列含 NULL，MySQL 会把 NULL 当作一个特殊值单独存储和比较。但问题在于：查询条件用 IS NULL 或 IS NOT NULL 时，索引利用率极低——尤其是 IS NOT NULL，在大多数版本中根本不会走索引（type=ALL），哪怕该列有索引。
常见错误现象：EXPLAIN 显示 key 为空、rows 等于全表行数、Extra 出现 Using where 但没 Using index。
- 普通索引对
IS NULL可能命中（取决于数据分布和优化器判断），但不保证； -
IS NOT NULL基本等价于全表扫描，别指望它用索引； - 联合索引中，如果最左列是空值占比高的字段，整个索引可能被跳过（违反最左前缀）；
- 空值越多，B+ 树中有效键值越稀疏，页内利用率下降，实际 I/O 效率变差。
什么时候该用唯一索引而不是普通索引？
当字段业务上“应唯一但允许缺失”时，UNIQUE INDEX 是更优选择——比如用户表的 email、id_card 字段，多数人填了，少数人没填（NULL），这时唯一索引既能防重复，又不强制非空。
关键区别在于：唯一索引对 NULL 不做唯一性校验（多个 NULL 允许共存），但对非空值严格去重；而普通索引不做任何约束。
- 建表时用
UNIQUE(email)，比INDEX(email)更贴近业务语义； - 查询
WHERE email = 'x@y.z'时，唯一索引能触发type=const或ref，性能优于普通索引； - 注意：不能对含大量
NULL的字段建唯一索引后还频繁查IS NULL——它依然不走索引； - 主键索引不允许
NULL，所以不能替代。
联合索引里空值字段放哪？尽量靠右，或直接剔除
联合索引遵循最左前缀，而空值字段参与排序时会导致“断层”：一旦某行该字段为 NULL，其索引项在 B+ 树中位置不确定，优化器倾向放弃使用该索引分支。
典型陷阱：建了 INDEX idx_a_b_c (a, b, c)，但 b 列 70% 是 NULL，那么 WHERE a = ? AND b IS NOT NULL 很可能不走索引，或只用到 a 部分。
- 高频查询条件中含空值字段时，优先把它移到联合索引最右侧；
- 如果该字段几乎只用于
IS NULL过滤，且结果集占比小，考虑改用覆盖索引 + 条件子查询，而非依赖它驱动联合索引； - 更激进的做法：用
COALESCE(b, -1)转成非空占位值（需同步改写查询），但要注意函数导致索引失效； - 真正有效的办法是评估该字段是否值得进联合索引——若空值率 > 30%，通常建议从联合索引中移除。
替代方案：用生成列 + 索引绕过空值干扰
MySQL 5.7+ 支持生成列（GENERATED COLUMN），可以把空值逻辑固化为确定性值，再对其建索引。这是目前最干净的解法。
例如：字段 phone 允许为空，但你想高效查“有手机号的用户”，可新增生成列：
ALTER TABLE users ADD COLUMN phone_filled TINYINT GENERATED ALWAYS AS (CASE WHEN phone IS NULL THEN 0 ELSE 1 END) STORED;
然后建索引：INDEX idx_phone_filled (phone_filled)。之后查 WHERE phone_filled = 1 就能稳定走索引。
- 生成列必须是
STORED类型才能建索引； - 避免在生成表达式里用
NOW()、UUID()等非确定性函数； - 这个技巧对
IS NULL/IS NOT NULL场景特别有效，但会增加少量存储开销； - 注意：应用层查询要同步改成基于生成列，不能继续写
phone IS NOT NULL。
空值本身不是索引杀手，但盲目建索引、忽略执行计划里的 key 和 rows 字段，才是让性能掉坑的真正原因。
