客户的销售总监抱怨：去年打开日报两秒，今年要四十秒，等数据出来人已经去开会了。查了一下，报表还是那个报表，订单表从三十万条涨到了五百万条，每次打开都在全量明细上实时聚合，数据库算得直喘气。后端系统开发的统计模块，数据量过百万就该换思路了。
汇总表是笨办法也是好办法
思路很朴素：别每次都从头算。每天凌晨把昨天的订单按天、按人、按商品聚合成一张汇总表，月底和年初的汇总也提前算好存着，报表查询直接打汇总表，几万条以内的数据，毫秒级返回。统计口径一旦定好，日、月、年三层汇总能把九成报表需求全部接住。这是报表系统的标准做法，说它笨，是因为多了一张表和一套定时任务；说它好，是因为稳、快、便宜。
实时和离线怎么取舍
- 经营日报、月度对账、销售排名，这些看趋势的数据，T加一天完全够用，全走汇总表；
- 真正需要实时的只有少数几个指标：今日实时销售额、当前在线人数，挑出来单独处理，加缓存或者增量更新，别让全站报表陪着它们实时；
- 老板临时要的跨维度自由分析，留给导出明细或专门的BI工具，别硬塞进业务系统的报表模块。
汇总表有个前提：口径必须和业务方确认死。销售额含不含退款、业绩按下单时间还是付款时间算，口径错了，报表算得再快也是错的。这份口径说明写下来存档，新报表开发时先对口径再写代码。
和汇总表配套的还有归档。三五年前的明细订单，日常查询几乎碰不到，却让每张表越来越臃肿。把两年前的数据挪进归档库，主库瘦身，索引效率立刻回升，归档库留着偶尔查历史。归档要配套一套查询入口，别归档完客户查三年前的单子查不到了，那就成了事故。
那位客户的改造做了两周：建了三层汇总表，凌晨任务聚合昨日数据，历史数据归档，日报打开回到一秒以内，月度经营会要的十几张报表全走汇总。顺带说一句，报表的访问高峰都在早上九点和周一上午，汇总任务务必在八点前跑完，别让总监们开会时数据还没出来。
报表快了才有人看
统计性能这件事的投入产出比极高：几张汇总表加一套凌晨任务，成本一周左右的开发量，换来的是管理层每天都要用的报表秒开。后端系统开发里最怕的就是把报表做成摆设，数据出来人已经散会，再准的数字也失去了价值。
两条建议：新系统立项时让开发方说明报表的统计方式，直接在明细表上实时聚合的方案，数据量一大必慢，提前留好汇总层；报表响应超过三秒的存量系统，按汇总表加归档的思路改造，比格网络做过不少这类瘦身，效果立竿见影，报表快了，数据才有人看。
