系统上线头三个月，老板要看今日订单数，一个count的事。第六个月，要看各区域各渠道各时间段的销售额对比、新老客复购率、退款率走势。报表越加越多，页面越开越慢，数据库CPU天天飘红。这时候问题就回到了数据库设计的起点：统计场景下，冗余该怎么用。
先分清「交易」和「统计」两条路
下单、改库存这类交易操作，必须走规范的表结构，保证数据准确。而统计是另一条路：读多、算重、对实时性其实没那么敏感。两条路混在同一条SQL里，就是慢的根源。让交易归交易，统计归统计，是处理报表问题的第一原则，想通这一条，后面的方案都好谈。
冗余的三种正经用法
- 汇总表：按天或按小时定时跑任务，把销售额、订单数算好存进一张汇总表，报表页直接读，毫秒级出结果。半夜跑十分钟的定时任务，换来白天所有人查报表不卡，怎么算都值。
- 宽表：把订单、用户、渠道几张表按分析需要拼成一张大宽表，定时刷新，做交叉分析时不用现场join五六张表。
- 计数冗余：文章评论数、店铺订单量这类单个数字，写入时顺手更新，读的时候直接取，省掉实时count。
冗余的代价要想清楚
冗余数据会不会不准？会，任务失败、并发冲突都可能弄脏。所以要有核对机制，比如每天凌晨拿汇总数和明细count对一遍，对不上就自动重算。允许分钟级延迟、有兜底核对，冗余才敢放心用，出了偏差也心里有数。
顺便提醒一句，汇总任务的粒度别贪细。见过有团队把汇总做到了分钟级，任务排队把数据库压得不轻，而业务方其实只会看天和看小时。粒度先粗后细，真有人要看小时级的数据再加，别一上来就把统计系统做成第二个业务库，那是给自己挖坑。统计和交易混在一个库里的项目，早晚要走到分库这一步，早规划早省事。
两条建议：报表需求多起来之前，就让开发把统计方案和交易表结构分开设计；汇总任务必须有失败告警和重跑入口，别指望谁天天盯着。比格网络做管理后台时，数据库设计上历来把统计模块独立处理再加每日核对，报表再多也不拖垮主业务，这套做法可以直接抄。
