SQL报表查询压力大时应动态伸缩资源，核心是感知负载与快速扩缩：先定位真实瓶颈（索引缺失、磁盘排序、连接打满等），再通过读写分离、缓存预计算、容器化自动扩缩容协同优化。
SQL报表查询压力大时，核心思路不是单纯加机器，而是让资源随查询负载动态伸缩——查得少时省成本，查得多时保响应。关键在“感知负载”和“快速扩缩”两个环节。
识别真实瓶颈，避免盲目扩容
报表慢不等于数据库CPU高。常见真因包括：大表全表扫描未走索引、临时表/排序内存不足触发磁盘交换、连接数打满导致新查询排队、或单个复杂报表长期占着执行计划缓存。
- 用EXPLAIN ANALYZE看执行计划，确认是否走了索引、是否有Seq Scan或Sort on disk
- 查pg_stat_statements（PostgreSQL）或sys.dm_exec_query_stats（SQL Server），定位耗时TOP 5的报表SQL
- 监控连接池使用率（如HikariCP的ActiveConnections），若长期>80%，说明并发能力已达上限
读写分离 + 只读副本弹性伸缩
报表属典型读多写少场景，主库专注事务，报表流量全部路由到只读副本集群。副本可按需增减，不影响主库稳定性。
- 用中间件（如ShardingSphere、MaxScale）或应用层配置多数据源，自动将SELECT语句发往副本组
- 云数据库（如RDS、Aurora）支持一键添加只读节点，扩容分钟级完成；自建环境可用Patroni+Consul实现副本自动发现与故障转移
- 为避免副本延迟影响报表准确性，对实时性要求高的报表加REPLICATION SLOT或设置max_standby_streaming_delay
查询层降压：缓存 + 预计算 + 超时熔断
很多报表查询重复度高（如日报、周报）、结果变化慢，直接缓存结果比反复查库更高效。
- 对参数化报表（如?date=2024-06-01®ion=sh），用Redis按参数哈希键缓存JSON结果，TTL设为业务可接受的过期时间（如1小时）
- 高频固定维度报表（如销售TOP10、区域同比），用物化视图或定时任务（Airflow）预聚合到宽表，查询走WHERE + INDEX即可秒出
- 在应用侧设置查询超时（如MyBatis的queryTimeout）和熔断（如Sentinel规则：5分钟内失败率>50%则自动拒绝后续同类请求）
资源层弹性：容器化 + 自动扩缩容
若报表服务独立部署（如Java报表API服务），可将其容器化，结合K8s HPA基于CPU/查询QPS/队列长度等指标自动扩缩实例数。
- 暴露自定义指标：在服务中埋点统计/report/sales?date=...的平均响应时间与每秒请求数，推送到Prometheus
- K8s HPA配置示例：targetCPUUtilizationPercentage: 60%，同时叠加keda-trigger监听Redis中待处理报表任务队列长度
- 数据库连接池同步调整：扩容后自动更新maxActive（Druid）或maximumPoolSize（HikariCP）避免连接争抢
