MAX/MIN未走索引因不满足三信号：Extra须为Select tables optimized away或Using index for group-by、rows≈1、无Using temporary/filesort；WHERE+极值需联合索引且等值字段在左、极值字段在右；GROUP BY+极值依赖MySQL版本及optimizer_switch设置；NULL字段、低区分度、成本估算偏差均可能导致索引被跳过。
MAX/MIN 为什么没走索引？先看 EXPLAIN 的三个关键信号
不是加了索引就自动生效。真正走极值索引优化的信号必须同时满足：Extra列出现Select tables optimized away（单表无WHERE）或Using index for group-by（GROUP BY场景），rows显示为1或极小固定值，且**绝对不能出现**Using temporary或Using filesort。如果只看到key非空、type: index，那大概率只是覆盖索引避免回表，不是极值定位。
WHERE + MAX/MIN 必须用联合索引，顺序不能错
单独给price建索引，执行SELECT MAX(price) FROM products WHERE category_id = 5仍会全表扫描——因为优化器无法用price索引去定位category_id = 5的范围。
- 正确做法：建
INDEX(category_id, price)，让等值过滤字段在左，极值字段在右 - 错误组合：
INDEX(price, category_id)无效；INDEX(category_id)+INDEX(price)也无效 - 若WHERE里是
IN或多个等值条件（如WHERE status IN ('a','b') AND type = 'x'），仍可用联合索引，但需把所有等值字段放前缀，极值字段紧随其后
GROUP BY + MIN/MAX 索引失效的常见原因
即使有INDEX(user_id, login_time)，SELECT user_id, MAX(login_time) FROM logs GROUP BY user_id在 MySQL 5.7 及更早版本中大概率触发Using temporary——优化器默认不启用松散索引扫描（Loose Index Scan）。
智能模型自动切换 V5.0.2 - 多模态感知，自动识别图片/视频/音频/代码/文本任务，切换最优模型。支持图片理解(qwen3-vl-plus)、视频音频(qwen3.5-plus)、代码(glm-5)、Office文档(MiniMax-M2.5)、推理等场景。零感知切换，无需手动操作。
- MySQL 8.0.13+ 需确认
optimizer_switch中skip_scan=on（默认开启），否则仍退化 - 查询字段顺序必须严格匹配索引顺序：
SELECT user_id, MAX(login_time)✔️；SELECT MAX(login_time), user_id❌ - 若
user_id区分度极低（如只有 2–3 个值），即使走索引，也可能因重复键值过多导致逻辑读飙升，此时不如直接扫表
NULL 值和字段定义会影响索引是否被选用
MIN()和MAX()天然忽略NULL，但索引能否高效跳转，取决于字段是否定义为NOT NULL。
- 字段允许
NULL且实际含大量NULL值时，优化器可能放弃极值索引优化，降级为普通索引扫描 - 主键或明确声明
NOT NULL的字段，优化器更倾向启用INDEX FULL SCAN (MIN/MAX)，EXPLAIN 中更容易见到Select tables optimized away - 别依赖
ORDER BY ... LIMIT 1替代MAX()——语义不同，且在某些复合条件或旧版本中，执行计划可能更差
最常被忽略的一点：索引能用，不代表一定被选。优化器会基于统计信息估算成本，如果它认为全表扫描比遍历索引叶子节点“更便宜”，就会跳过索引。所以建完联合索引后，务必用真实数据量跑EXPLAIN，盯紧rows和Extra，而不是只看key有没有命中。
