WHERE中COALESCE(status, 'active') = 'active'会导致索引失效，因数据库需逐行计算函数结果而无法使用B+树索引；正确写法是拆分为status = 'active' OR status IS NULL，或建生成列索引（如MySQL 5.7+的STORED列+索引）。
WHERE 中 COALESCE(status, 'active') = 'active' 会失效索引
因为 MySQL（及其他主流数据库）无法对函数包裹的列直接使用索引。优化器看到 COALESCE(status, 'active')，就得先逐行计算结果，再比对，彻底放弃走 status 字段上的 B+ 树索引。
- 真实执行计划里会出现
type: ALL或Extra: Using where，而不是type: ref或key: status_index - 哪怕
status上建了联合索引（如(status, created_at)），只要被COALESCE包裹，整个索引前缀就失效 - PostgreSQL 和 SQL Server 同样如此——函数调用阻断索引下推，不是 MySQL 特有 bug
怎么写才能让 status = 'active' 或 IS NULL 走索引
把逻辑拆开，用布尔组合替代函数封装，让优化器能分别命中索引分支。
- ✅ 正确写法：
WHERE status IS NULL OR status = 'active'—— 多数情况下能触发index_merge或松散索引扫描 - ✅ 更稳写法（MySQL 5.7+）：
WHERE status IN ('active') OR status IS NULL，配合status单列索引即可高效执行 - ⚠️ 注意：如果表里
status IS NULL占比极高（比如 > 20%），优化器可能仍选全表扫描——这时得看实际EXPLAIN输出，不能只信写法
想长期解决空值查询性能，该建什么索引
生成列 + 索引是真正治本的办法，但要注意版本和存储类型限制。
- 先加生成列：
ALTER TABLE t ADD COLUMN status_clean VARCHAR(20) STORED AS (COALESCE(status, 'active')); - 再建索引：
CREATE INDEX idx_status_clean ON t(status_clean); - ⚠️
STORED是必须的——VIRTUAL列不能建索引；MySQL 5.7.6+ 才支持 - 后续查询直接写：
WHERE status_clean = 'active'，就能稳定走索引
ORDER BY 里用 COALESCE 也会影响索引吗
会，而且更隐蔽。即使字段本身有索引，ORDER BY COALESCE(name, 'zzz') 通常导致 filesort。
- 原因：排序键不再是原始列值，而是计算后结果，无法复用
name的有序结构 - MySQL 8.0+ 推荐改用
ORDER BY name NULLS LAST，既语义清晰，又可命中索引（前提是索引定义含ASC） - 字符串字段慎用占位符如
'~'或'ZZZZ'：若真实数据里真有这些值，排序会混入，且类型隐式转换可能引发截断
