索引在 GROUP BY 日期字段时未生效，主因是 WHERE 条件对日期字段使用函数、类型不匹配或联合索引不满足最左前缀；例如 DATE(log_time) = '2026-07-15' 会阻止索引使用，应改用 log_time >= '2026-07-15' AND log_time < '2026-07-16'。
索引在 GROUP BY 日期字段时没生效，大概率不是分组本身的问题，而是查询写法或索引结构不匹配导致优化器主动弃用索引——尤其当 WHERE 条件里对日期字段用了函数、类型不一致，或联合索引没满足最左前缀时。
WHERE 中对日期字段用函数（最常见原因）
哪怕你只为分组，只要 WHERE 子句里写了 YEAR(create_time) = 2025 或 DATE(log_time) = '2026-07-15'，数据库就必须逐行计算函数结果，无法利用 create_time 或 log_time 上的索引定位数据范围，自然也谈不上后续分组能走索引扫描。
- 错误写法：
SELECT DATE(log_time), COUNT(*) FROM logs WHERE DATE(log_time) = '2026-07-15' GROUP BY DATE(log_time) - 正确写法：
SELECT log_time, COUNT(*) FROM logs WHERE log_time >= '2026-07-15' AND log_time （注意：<code>GROUP BY仍可用函数，但WHERE必须裸字段） - 更优写法：
GROUP BY log_time（如果精度够用），或建生成列索引：ALTER TABLE logs ADD COLUMN log_date DATE AS (DATE(log_time)) STORED，再对log_date建索引
GROUP BY 字段和索引顺序不一致
如果你建的是联合索引 (status, create_time)，但查询是 GROUP BY create_time，即使 create_time 在索引里，它不在最左位置，MySQL 无法直接按该字段做有序分组，大概率退化为临时表 + filesort。
- 联合索引要支持
GROUP BY date_col，该列必须是索引最左列，或至少是前缀连续部分（如索引(date_col, user_id)可用于GROUP BY date_col） - 若还需
WHERE status = 'done'，建议建(status, date_col)—— 等值条件放前，分组字段紧随其后 - 执行前务必用
EXPLAIN看type是否为range或ref，且Extra不含Using temporary; Using filesort
日期字段类型或值异常
索引存在，但字段本身是 VARCHAR 类型存 '2026/07/20' 这种格式，或含非法值（如 '0000-00-00'、空字符串），MySQL 无法按时间语义排序索引项，优化器会认为走索引比全表扫描还慢。
- 检查字段类型：
SHOW COLUMNS FROM table_name LIKE 'date_col';，确认是DATE/DATETIME/TIMESTAMP - 查异常值：
SELECT date_col FROM table_name WHERE date_col NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}'; - 修复方式：
ALTER TABLE table_name MODIFY date_col DATE;，再用UPDATE清洗脏数据
真正关键的不是“能不能分组”，而是“优化器有没有机会用索引把数据提前过滤并保持有序”——一旦 WHERE 破坏了字段裸露，或索引结构不贴合查询模式，分组就只能在内存或磁盘临时结构里硬算。动手前先 EXPLAIN，别猜。
