SELECT * 会让覆盖索引失效，因其隐式请求表中所有列，而覆盖索引要求查询涉及的全部字段（SELECT、WHERE、ORDER BY、GROUP BY 等）均被索引 key 或 INCLUDE 列完全包含。
为什么 SELECT * 会让覆盖索引失效
覆盖索引（Covering Index）的前提是：查询所需的所有字段，全部包含在索引的 key 或 include 列中，无需回表查聚簇索引。而 SELECT * 会隐式要求所有列，哪怕你只建了部分列的索引，优化器也大概率放弃使用它——因为无法保证“所有列”都在索引里。
常见错误场景：给 (user_id, create_time) 建了联合索引，却写 SELECT * FROM orders WHERE user_id = 123。此时即使 create_time 是查询条件或排序字段，只要表还有 amount、status 等未被索引覆盖的列，MySQL/PostgreSQL 就会弃用该索引做覆盖扫描，转而走索引 + 回表，甚至全表扫描。
- MySQL 中可通过
EXPLAIN的Extra字段确认：Using index表示命中覆盖索引；Using index condition+Using where不等于覆盖，只是用了 ICP；出现Using filesort或Using temporary往往已脱离覆盖路径 - PostgreSQL 需看
EXPLAIN (ANALYZE)中是否出现Index Only Scan；若为Index Scan并伴随Heap Fetches > 0，说明发生了回表 - SQL Server 要检查执行计划里是否为
Index Seek (Non-Clustered)且Output List完全由索引列构成，不含[table].[column]这类堆/聚簇列引用
哪些列必须显式写出才能触发覆盖索引
不是“只写索引里的列”就够，而是查询语句中 SELECT、WHERE、ORDER BY、GROUP BY 涉及的所有列，都得被索引覆盖（含 INCLUDE）。漏掉任意一个，就破防。
例如有索引 IX_orders_user_status_incl_amount (user_id, status) INCLUDE (amount)：
- ✅
SELECT amount FROM orders WHERE user_id = 123 AND status = 'paid'→ 覆盖成立 - ❌
SELECT amount, updated_at FROM orders WHERE user_id = 123→updated_at未被索引，强制回表 - ⚠️
SELECT user_id, status FROM orders ORDER BY user_id, status→ 若索引是(user_id, status)且无INCLUDE，仍可覆盖（排序字段也在 key 中），但加了LIMIT 1000后若优化器预估需跳过大量行，可能改用全表扫描
ORDER BY 和 GROUP BY 对覆盖索引的隐形破坏
即便 SELECT 和 WHERE 全部命中索引，ORDER BY 或 GROUP BY 引用的列如果不在索引最左前缀连续序列中，也会导致覆盖失败。MySQL 尤其敏感：它要求排序字段必须是索引的后缀连续部分，且方向一致（ASC/DESC 不能混）。
- 索引为
(a, b, c)，ORDER BY a, b✅；ORDER BY a, c❌（跳过了b）；ORDER BY b, c❌（没以a开头） - PostgreSQL 更宽松些，支持索引跳跃扫描（
Bitmap Index Scan+Sort），但这时已不算“覆盖”，因为多了排序开销和内存消耗 -
GROUP BY x, y同理：若索引是(x)单列，哪怕SELECT x, COUNT(*)，也无法避免对y的额外访问（除非用物化视图或生成列索引）
NULL 值和函数表达式让覆盖索引彻底失效
索引本身不存储 NULL（B+Tree 实现差异下，MySQL 的二级索引允许 NULL，但优化器常保守处理），更不存储计算结果。一旦 SELECT 或 WHERE 出现表达式，基本告别覆盖。
- ❌
SELECT id, UPPER(name) FROM users WHERE city = 'Beijing'→UPPER(name)是计算列，不在索引中 - ❌
SELECT * FROM logs WHERE DATE(created_at) = '2024-01-01'→ 函数作用于索引列，无法走索引范围扫描，更别说覆盖 - ⚠️
SELECT id, name FROM users WHERE deleted_at IS NULL→ 若deleted_at是可空列，且索引未特别设计（如加WHERE deleted_at IS NULL的过滤索引），优化器可能认为 NULL 分布稀疏而弃用索引
真正安全的做法，是把表达式逻辑前置到应用层，或建函数索引（PostgreSQL 支持 CREATE INDEX ON t ((UPPER(name)))；MySQL 8.0+ 支持函数索引但仅限于虚拟列 + 普通索引组合）。
