能，但需单列索引覆盖查询字段且WHERE条件不破坏索引有序性；复合条件时应将等值字段置左、范围字段置右，并确保极值字段在索引中位置可直接定位。
MySQL 的 MIN() 和 MAX() 能走索引吗？
能，但只在特定条件下——必须是**单列索引覆盖查询字段**，且**WHERE 条件不破坏索引有序性**。比如 SELECT MIN(id) FROM t WHERE status = 1，即使 id 有索引，如果 status 没参与联合索引，就大概率退化为全表扫描。
根本原因：MySQL 优化器想用索引快速定位极值，就得依赖 B+ 树叶子节点的物理有序性。一旦查询需要先过滤再找极值（如先筛 status=1 再取 MIN(created_at)），就必须确保筛选字段和极值字段在同一个索引里按顺序排列。
- ✅ 正确姿势：
CREATE INDEX idx_status_created ON t (status, created_at)→SELECT MIN(created_at) FROM t WHERE status = 1可直接跳到第一个匹配status=1的叶子节点，取其created_at值 - ❌ 常见错误：只建了
INDEX(created_at)，WHERE 里却带status过滤 → 优化器无法利用created_at索引做范围裁剪，只能扫全表 - ⚠️ 注意：
MIN()/MAX()对NULL的处理和索引是否允许NULL有关；若字段定义为NOT NULL，优化器更倾向启用索引扫描
为什么 GROUP BY + MIN/MAX 经常不走索引？
因为 MySQL 在分组聚合时，默认会尝试用临时表 + 文件排序（Using filesort），而不是逐组走索引。哪怕你给 GROUP BY a 和 MIN(b) 都建了索引，也不代表它能跳着查。
关键看执行计划里有没有 Using index for group-by —— 这个提示才表示真正用了索引下推优化。没看到？那基本就是先扫、再分组、再算极值。
- ✅ 可行方案：建联合索引
(a, b)，且查询写成SELECT a, MIN(b) FROM t GROUP BY a（注意顺序不能反） - ❌ 错误假设：以为
INDEX(a)+INDEX(b)就够了 → 多个单列索引无法协同完成有序分组 - ⚠️ 性能陷阱：如果
a区分度极低（比如只有 3 个值），即使走了索引，也可能因回表或扫描大量重复键值而变慢
EXPLAIN 里哪些信号说明 MIN/MAX 真正用了索引？
别光看 type: index 或 key 字段非空——那是基础门槛。重点盯这三个地方：
-
Extra列出现Using index for group-by或Select tables optimized away（后者表示整个查询被优化成常量，比如SELECT MIN(pk) FROM t且表非空） -
rows显示为 1 或很小的固定值（不是几万几十万） - 没有
Using temporary和Using filesort
如果 Extra 里写着 Using where; Using index，但 rows 很大，说明它只是用索引避免回表，实际仍在遍历满足 WHERE 的所有索引项——这不是你想要的“极值秒出”效果。
复合条件下的 MIN/MAX 索引设计要点
现实场景往往带多个过滤条件，比如 SELECT MIN(updated_at) FROM logs WHERE app = 'web' AND level >= 3 AND updated_at > '2024-01-01'。这时候索引字段顺序决定一切。
- 优先把等值条件（
=）字段放最左：如app是高频等值筛选，必须放索引第一位 - 接着放范围条件（
>=,BETWEEN），但注意：一个范围之后的字段，索引就失效了 → 所以level >= 3后不能再指望updated_at走索引范围扫描 - 因此正确索引是
INDEX(app, updated_at)（把时间范围提前），让MIN(updated_at)直接落在索引扫描起点；level放后面仅用于过滤，不参与索引查找逻辑 - ⚠️ 容易忽略：如果
updated_at > '2024-01-01'返回数据量极大，即使走了索引，MIN()仍要从第一个匹配项开始往后扫，直到找到第一个非空值——此时加LIMIT 1没用，MIN()本身就是聚合语义
最麻烦的情况是 WHERE 里混用 IN 和范围条件，这时优化器大概率放弃索引下推，老老实实走临时表。真遇到，要么拆查询，要么加冗余覆盖索引，别硬扛。
