SQL如何高效导出大规模的分组汇总数据_利用分页与索引

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 流。 标贝科技 标贝科技-专业AI语音服务的人工智能开放平台