SQL 报表大文件生成慢的核心原因是同步执行阻塞用户请求，解决方法是异步化：分离查询与导出、流式写入、Redis 缓存临时结果、消息队列驱动任务、优化 SQL 索引与聚合、增加进度反馈和断点续传。
SQL 报表大文件生成慢，核心原因是同步执行阻塞了用户请求，尤其在数据量大、计算复杂时，前端长时间等待易超时或卡死。解决思路是把耗时操作移出主线程，改用后台异步生成，用户提交后立即返回，再通过轮询、消息通知或下载链接获取结果。
拆分任务：SQL 查询与文件导出分离
避免在同一个事务里查完立刻写 Excel/CSV。先执行 SQL 获取结果集（可缓存到临时表或 Redis），再由独立任务读取并转为文件。这样数据库连接不被导出逻辑拖住，也方便失败重试。
- 查询阶段只做 SELECT，限制字段和分页（即使全量导出，也可分批查）
- 导出阶段用流式写入（如 Apache POI SXSSF、Python 的 csv.writer），不全量加载进内存
- 临时结果存带 TTL 的键值存储（如 Redis），过期自动清理
用消息队列驱动异步任务
用户点击“导出”后，后端不执行 SQL，而是发一条消息（如 RabbitMQ/Kafka）到任务队列，由工作进程消费并执行真实导出。解耦清晰，支持横向扩展和失败监控。
- 消息体包含报表 ID、参数、用户 ID、回调地址（或通知方式）
- 工作进程执行完后，更新任务状态表，并触发邮件 / 站内信 /Webhook 通知
- 前端通过 /api/task/status?task_id=xxx 轮询状态，成功后返回文件 URL
优化 SQL 与存储层性能
异步只是掩盖问题，不是根治。大报表慢常因 SQL 没走索引、全表扫描、JOIN 过多或聚合函数无过滤。需配合数据库层面调优：
- 给 WHERE、GROUP BY、ORDER BY 字段建联合索引，覆盖查询所需列（避免回表）
- 用 EXPLAIN 分析执行计划，确认是否用上索引、是否有临时表或文件排序
- 对历史归档数据建汇总表（如按天 / 月预聚合），报表优先查汇总表
- 超大数据量考虑物化视图（PostgreSQL）或 ClickHouse 等 OLAP 引擎支撑
提供进度反馈与断点续传能力
用户不希望“黑盒等待”。可在任务中记录当前处理行号或批次，前端按需展示进度条；若导出中断（如服务重启），支持从断点继续，而非重头再来。
- 任务表增加 progress（0-100）、current_offset、total_count 字段
- 分页导出时，每处理 1 万行更新一次进度，避免高频写库
- 文件按批次写入对象存储（如 OSS/S3），最终合并或直接提供分片下载链接
