group by 慢主因是分组字段未走索引，需手动创建匹配顺序的复合索引；分页导出应改用游标分页；select into outfile 并非总更快，流式查询更可控；distinct/json_agg 易引发内存溢出，宜近似计算或拆步处理。
GROUP BY 太慢？先看执行计划里有没有用上索引
分组汇总慢，八成不是 SQL 写得差，而是 GROUP BY 字段没走索引。MySQL/PostgreSQL 都不会自动给分组字段建索引，得你手动加。比如按 user_id 和 created_date 分组统计，但表里只有主键 id，那全表扫描就躲不掉。
实操建议：
- 用
EXPLAIN查看type是否为index或range，别信“rows 很小”——那是估算值，实际可能扫全表 - 复合索引顺序必须匹配
GROUP BY的字段顺序，CREATE INDEX idx_user_date ON orders(user_id, created_date)才能加速GROUP BY user_id, created_date - 如果分组字段有
WHERE条件，优先把过滤字段放索引前面，比如WHERE status = 'paid' GROUP BY user_id，索引应为(status, user_id)
导出千万级结果时，别用 OFFSET LIMIT 分页
OFFSET 1000000 LIMIT 1000 看似合理，但数据库仍要数前 100 万行，CPU 和 I/O 压力陡增，延迟飙升。这不是导出瓶颈，是分页逻辑本身反模式。
实操建议：
- 改用游标分页：记录上一页最后一条的
group_key（比如MAX(user_id)），下一页查WHERE user_id > ? GROUP BY ... - 确保游标字段有索引，且类型稳定（避免用
UUID或浮点数做游标） - 导出脚本里每次查询加
LIMIT 5000，太大容易超时；太小则网络往返多，5k 是多数 OLTP 场景的平衡点
SELECT INTO OUTFILE 不一定比应用层导出快
SELECT INTO OUTFILE 看起来“数据库直出”，但实际受限于磁盘权限、路径可见性、单线程写入，反而常成瓶颈。尤其当目标文件要写到 NFS 或云存储挂载点时，I/O 吞吐可能不如应用边查边写 CSV 流。
实操建议：
-
SELECT INTO OUTFILE只适用于 MySQL 本地磁盘，且用户需有FILE权限，生产环境常被禁用 - PostgreSQL 用
COPY ... TO更可控，但同样受服务端磁盘和权限限制 - 更稳的路子：用流式查询（如 Python 的
cursor.stream_results=True+csv.writer），内存只存当前批次，不攒全量结果
聚合字段含 DISTINCT 或 JSON_AGG 时，内存会炸
COUNT(DISTINCT user_id) 或 JSON_AGG(row_to_json(...)) 在分组量大时，数据库要为每个分组维护临时哈希表或数组，极易触发 sort_buffer_size 不足或 work_mem 溢出到磁盘，速度断崖下跌。
实操建议：
- 先确认是否真需要精确去重——近似去重用
APPROX_COUNT_DISTINCT（BigQuery/Trino）或HLL插件（PostgreSQL）快十倍以上 - 避免在单条 SQL 里既聚合又收集明细，拆成两步：先
GROUP BY出主键列表，再用IN或JOIN查详情 - PostgreSQL 中
JSON_AGG超过几千行建议加LIMIT，或者改用应用层组装
真正卡住的往往不是语法，而是索引没对上、游标没选对、聚合函数暗地吃内存——这些地方一动，导出时间从小时级掉到分钟级，但很容易被当成“数据量太大”直接放弃优化。
