SQL的分组查询慢，多半是GROUP BY没走上索引的“快车道”。很多人第一反应是加索引，但加完一看，Using temporary、Using filesort照样冒出来——这说明索引根本没被用对。
那么，到底怎么排查，怎么建索引，哪些写法要避开？一句话讲不清，咱们摊开说。
EXPLAIN 里出现 Using temporary 怎么办？
这不是警告，是确诊书：MySQL 正在把中间结果写进临时表，内存不够就落盘，I/O 直接拉垮。别急着调 tmp_table_size，先看索引有没有对上。
- 检查
EXPLAIN的type字段：要是ALL或index，说明没走有效索引 - 确认
key_len是否合理：比如字段定义是VARCHAR(255)，但查询只用前10字符，key_len却显示 765，说明索引定义和实际使用不匹配 Extra出现Using where; Using index是好信号；只要带Using temporary或Using filesort，覆盖索引就没生效
联合索引字段顺序怎么排才对？
顺序错了，宽索引也白建。核心就一条：WHERE 条件字段最左，GROUP BY 字段紧随其后，SELECT 中聚合依赖字段放末尾。
- 例如查询
SELECT dept_id, COUNT(*), SUM(amount) FROM orders WHERE status = 'paid' GROUP BY dept_id，索引必须是INDEX idx_status_dept_amount (status, dept_id, amount) - 写成
(dept_id, status)或(status, amount, dept_id)都不行——前者WHERE用不上，后者分组字段不在连续前缀里 - 别把
remark、content这类大字段塞进索引，写入放大和缓存压力会陡增
哪些写法会让索引彻底失效？
哪怕索引建得再准，这几类操作一出现，优化器就直接放弃它。
GROUP BY YEAR(created_at)、WHERE UPPER(name) = 'ADMIN'：函数调用破坏索引有序性WHERE user_id = '123'（user_id是INT）：隐式类型转换导致无法使用索引SELECT *：主键以外字段大概率不在索引里，必然回表，覆盖索引失效WHERE remark LIKE '%abc'：前导通配符破坏最左前缀匹配
高基数字段分组卡住怎么办？
对 UUID、手机号、长文本做 GROUP BY，不是因为没索引，而是每个值太“散”，内存装不下分组桶，tmp_table_size 再大也救不了。
- 优先逻辑降维：把 IP 归到地区，邮箱截取域名，用预计算列替代原始字段分组
- 检查是否真需要按高基数字段分组——能不能聚合到部门、城市、日期等更高层级？
- 如果必须按唯一值统计，考虑用
APPROX_COUNT_DISTINCT（MySQL 8.0+）或 HyperLogLog（PostgreSQL 扩展），换精度保速度
真正容易被忽略的是：索引顺序、函数使用、高基数字段这三点，往往在开发阶段就埋下隐患，等数据量涨到千万级才爆发。调参只是补救，结构设计才是根因。
