慢SQL优化案例：月度报表从0.8秒到0.07秒（PostgreSQL）产品系统

很多业务系统上线几年后数据量变大，月度报表、统计查询越来越慢，页面超时、数据库CPU升高。本案例模拟一个典型场景：订单表500万行、客户表20万行，按地区统计某月已支付订单的金额和购买客户数。原写法在列上套了函数，导致索引失效，只能全表扫描。

本案例展示一次完整的慢SQL优化过程：
1. 问题定位：用 EXPLAIN (ANALYZE, BUFFERS) 获取实测执行计划，找出全表扫描和被过滤掉的约490万行数据；
2. 查询改写：去掉列上的 to_char、lower 函数，改为时间范围条件；先按客户聚合，再关联地区，减少关联和去重的数据量；
3. 索引设计：只为已支付订单建立部分覆盖索引（INCLUDE customer_id、amount），实现仅索引扫描；索引110MB，比全量覆盖索引（249MB）小一半以上；
4. 结果校验：优化前后的查询结果逐行比对，完全一致；
5. 交付物：分析报告、优化前后执行计划、索引与改写SQL、回滚脚本。

本人独立完成数据构造、问题分析、SQL改写、索引设计和测试。
环境：PostgreSQL 18，脚本生成的模拟数据，不含任何客户信息。
结果：同一台机器各跑7次取中位数，执行时间从799毫秒降到72.6毫秒，快约11倍；读取的数据页从约28.5万降到约4.5万。
经验：慢SQL多数不是数据库不行，而是写法让索引用不上。优化前先确认业务口径（状态值大小写、时区和月份边界），再改写，最后必须做结果一致性校验，避免“变快了但数据错了”。同样的方法也适用于MySQL、Oracle、SQL Server。