group by 对计算列无法命中索引，根本原因是索引只存储原始列值或显式定义的生成列值，不存储表达式结果；b+树中无year(created_at)等计算值，故必须全表扫描并逐行计算，触发using temporary。
GROUP BY 对计算列（如 YEAR(created_at)、UPPER(email)、COALESCE(status, 'unknown')）无法命中索引，根本原因不是 MySQL “不支持”，而是**索引本身不包含这些计算结果**——B+树索引只存储原始列值或生成列的显式存储值，不会自动为表达式建索引。
MySQL 的索引不存表达式结果，只存原始/显式值
索引是物理结构，它按你定义的列或生成列内容排序存储。写 GROUP BY YEAR(created_at) 时，优化器发现没有哪个索引的 B+ 树节点里存着“2026”这个年份值——哪怕 created_at 有索引，树里存的仍是完整时间戳（如 '2026-10-13 16:07:00'），没法直接跳到某一年的起始位置。
- 普通索引对
created_at有效，但对YEAR(created_at)无效：优化器必须先读出所有行，再逐行计算年份，再分组 → 必然触发Using temporary - 即使加了函数索引（MySQL 8.0+），也得显式创建：
CREATE INDEX idx_created_year ON t ((YEAR(created_at)))；括号不能少，否则语法报错 - 旧版本 MySQL（
为什么用生成列（STORED）+ 索引就能行？
生成列把计算逻辑“固化”进表结构，让索引能真正覆盖它。例如：
ALTER TABLE orders ADD COLUMN created_year INT AS (YEAR(created_at)) STORED; CREATE INDEX idx_created_year ON orders (created_year);
这时 GROUP BY created_year 就能走索引，因为：
-
created_year是真实列，值在插入/更新时已算好并持久化 - 索引
idx_created_year的 B+ 树里存的就是整数2026、2025等，可直接用于松散索引扫描 - 执行计划中
Extra会出现Using index for group-by，而非Using temporary
常见误判：以为加了索引就万事大吉
很多人给原始列建了索引，就默认函数分组也能加速，结果 EXPLAIN 一看还是 type: ALL。容易踩的坑包括：
- 索引是
(created_at)，但写GROUP BY DATE(created_at)：日期截断 ≠ 年份提取，仍不匹配 - 用了
CAST或CONVERT：如GROUP BY CAST(price AS SIGNED)，没对应生成列和索引，照样失效 - WHERE 和 GROUP BY 混用函数：比如
WHERE MONTH(created_at) = 10 GROUP BY YEAR(created_at)，两个函数都无索引支撑，双重全表扫描 - 字符集隐式转换干扰：如
GROUP BY UPPER(name)，而name是utf8mb4_bin，函数结果可能触发字符集降级，使索引失效
真正起作用的永远不是“写了 GROUP BY”，而是“有没有一个索引，其键值和 GROUP BY 表达式输出完全一致”。函数、类型转换、NULL 处理、字符集——任何一步脱钩，索引就形同虚设。
