17370845950

覆盖索引指查询所需字段全部包含在索引中，避免回表；联合索引按最左前缀原则排序，高频等值列置左、范围查询列置右，二者协同设计以减少I/O、免排序、少回表。

覆盖索引和联合索引不是“选一个用”，而是根据查询模式协同设计的两种关键手段。真正提升性能的关键，在于让数据库尽量少读数据页、少回表、少排序——索引就是为这个目标服务的。

什么是覆盖索引？为什么它快？

覆盖索引指：查询所需的所有字段，全部包含在索引的键列（或包含列）中，无需回表查聚簇索引。MySQL 的二级索引叶子节点存的是主键值，如果 SELECT 的列都在该索引里，引擎直接从索引树返回结果，跳过聚簇索引查找。

例如：
SELECT user_id, status FROM orders WHERE order_date > '2025-01-01';
若存在索引 INDEX idx_date_status (order_date, status)，但没包含 user_id，则仍需回表取 user_id；若建为 INDEX idx_cover (order_date, status, user_id)，就构成覆盖索引。

• 覆盖索引减少 I/O：避免额外的聚簇索引随机读
• 适用于高频、轻量、只读场景（如状态列表、统计摘要）
• 注意：过多包含列会增大索引体积，影响写入和缓存效率

联合索引怎么排序？最左前缀到底怎么用？

联合索引按定义顺序构建 B+ 树：先按第一列排序，相同时再按第二列，依此类推。因此，只有满足“连续且从左开始”的列条件，才能高效利用索引进行范围扫描或等值查找。

对于索引 INDEX idx_u_s_t (user_id, status, create_time)：

• ✅ WHERE user_id = 100 AND status = 'paid' → 可走索引前两列
• ✅ WHERE user_id = 100 ORDER BY create_time → 索引天然有序，免排序
• ❌ WHERE status = 'paid' → 跳过首列，无法使用该索引（除非是 MySQL 8.0+ 的跳跃扫描，但有前提）
• ⚠️ WHERE user_id > 100 AND status = 'paid' → status 列失效，仅用于过滤，不参与范围扫描

怎么设计高效的联合索引？三个实操原则

别靠猜，看执行计划（EXPLAIN）+ 查询频率 + 数据分布。重点考虑三件事：

• 高频等值条件放最左：如 user_id 出现在 90% 查询中，就优先作为第一列
• 范围查询列只放最后：>、>=、create_time 放末尾，前面可接多个等值列
• 把排序/分组字段纳入索引末尾：如常查 WHERE user_id = ? AND status = ? ORDER BY update_time，索引应为 (user_id, status, update_time)，避免 filesort

覆盖索引 + 联合索引组合优化示例

业务场景：运营后台查“某用户近30天已完成订单数及总金额”

SQL：
SELECT COUNT(*), SUM(amount) FROM orders
WHERE user_id = 123
AND status = 'completed'
AND create_time >= '2025-05-01';

最优索引：
INDEX idx_user_status_time_amt (user_id, status, create_time, amount)

说明：

• 前三列满足最左前缀：精确过滤 user_id + status + 时间范围
• amount 加入索引末尾，使聚合函数 SUM(amount) 直接走索引，无需回表
• COUNT(*) 也受益：引擎遍历索引即可计数，不访问数据行
• 注意：不要加主键 ID —— 这里根本不需要它，徒增索引大小