如何提高SQL分组查询在大数据量下的执行性能与效率

EXPLAIN出现Using temporary说明MySQL正写入临时表，需检查索引：type不能为ALL/index，key_len需匹配实际使用长度，索引顺序应为WHERE字段→GROUP BY字段→聚合依赖字段，避免函数、隐式转换和高基数字段直接分组。

直接加索引不等于解决问题，关键得让 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 扩展），换精度保速度

真正容易被忽略的是：索引顺序、函数使用、高基数字段这三点，往往在开发阶段就埋下隐患，等数据量涨到千万级才爆发。调参只是补救，结构设计才是根因。