报表一跑，下单就慢：分析查询该放哪

一、先看一个具体的月底

月底最后一天，财务要一张按客户、按区域、按业务员汇总的销售表，运营同时要看退货率和回款进度。

报表一点，订单页开始转圈。客服那边，客户正等着确认发货。

老板的第一反应通常是加机器，或者问一句：是不是该上数据仓库了。

先别急。先看清慢发生在哪里。

二、慢的不是报表，是两种活挤在一起

业务库同时干着两件性质相反的事。

下单、改单、收款是小的读写，一次只碰几行，要求几十毫秒内返回。

报表是一次扫几十万行，再做分组和排序，跑几十秒也正常。这类查询后面统称分析查询：不是为了改一笔数，而是为了把很多数加总、比较、排序。

两种活抢的是同一份资源：处理器、磁盘、内存、数据库连接。报表一占住，下单就排队。

机器加一档能缓一阵。但数据每天都在长，报表也会跟着变重，过几个月又撞上。

2026 年 9 月，一家云厂商公布的一个案例里，交易和分析分开之后，交易页面的慢请求从 2.5 秒降到 15 毫秒，分析查询从 45 秒降到 0.8 秒。厂商案例的数字通常挑好的说，但方向值得看：这两类活的脾气本来就不一样。

三、先量三件事，再谈选哪条路

动手之前先量三件事。答案不同，选的路也不同。

第一，报表有多重。最慢的一条跑多久，一次扫多少行，每天跑几次，是不是都挤在月底。

第二，数据要多新。老板要的是昨天的数、上一小时的数，还是刚刚发生的数。

第三，业务能等多久。报表跑五分钟没人会出事；下单多等两秒，客户就可能走了。

这三件事比技术偏好重要。很多选型争吵，吵的其实是这三个问题没答清。

四、四条路，花费差一个数量级

常见做法只有四条，从便宜到贵排得出来。

第一条，留在业务库，但给报表加上限制。

第二条，加一台只读副本，让报表去副本上跑。

第三条，做汇总表，把重活提前算好。

第四条，单独建分析库或数据仓库。

四条路的价钱差得很远：前两条是多一点配置或一台机器，后两条要多一套任务、一套系统，还要多一个人照看。

不是越往后越好。每往后走一步，多出来的维护工作都要有人接。

五、第一条路：留在业务库，但把活动范围管起来

报表还查业务库，但把它的活动范围管起来。

给报表单独一个只读账号，设查询超时，限制同时能跑几条；把报表排到业务低峰；最常用的筛选字段加索引。

索引就是数据库用来少翻行的一本目录。有了它，找几十条记录不用把整张表翻一遍。

这些动作当天就能做，花费很小。但它只挡得住小报表。数据量一上来，再好的索引也救不了一次几百万行的汇总。

适用的情况很具体：数据量不大，报表不多，一天跑几次，老板能等到第二天。

六、第二条路：只读副本，便宜，但不是隔离

主库负责写，副本持续接收主库的改动，报表连到副本上查。

多数云数据库点几下就能加一台，费用是一台机器的钱。它把报表的读请求从主库挪走了，下单最先受益。

但副本不是隔离。它跑的是同一套数据库软件，复杂查询照样吃处理器和磁盘；副本自己被拖慢时，接收主库改动也会跟着落后。

更准确的说法是：副本是另一台同样的机器，不是一台专门为报表准备的机器。

2026 年 8 月，一篇运维文章里提醒过同一个画面：所有副本都开放给业务读，报表任务一跑，整个应用跟着变慢。

七、副本的旧数问题，必须提前说清

副本还有一个毛病：它给的是旧数。

主库写完，副本要过一会儿才收到。正常时只差毫秒到几秒，主库忙起来可能差几分钟。

于是刚下的单在报表里查不到，刚改的客户名还是旧的。

老板拿报表对当天业绩，就会问：系统里明明有一单，报表为什么没有。

处理办法只有三条：报表上写明截至几点；少数必须看当天的表改查主库；或者上实时同步。三条各有代价，不能假装这个问题不存在。

八、第三条路：汇总表，把重活提前做完

每天晚上或每小时，把明细算成一张小表：按天、按客户、按区域的总数。

报表查这张小表，通常只有几万行，几秒就出来。业务库只承担一次汇总任务，不用陪报表跑一整天。

它适合指标固定的场景：销售额、回款额、退货率、客户排名。看趋势、看排名、看同比，都是它擅长的。

代价是多一个定时任务、多一张表、多一套补数据的办法。三样缺一样，这张表迟早没人敢用。

九、汇总表最容易坏在两件事上

第一件，统计规则变了。退货算不算收入，跨月的订单算哪个月，取消的单要不要扣回去。

规则一改，历史数就得重算。不然新旧两张报表对不上，开会时没人知道该信哪张。

第二件，补数没人管。任务失败、漏了一天、源数据被修正，都要能重跑某一天，并且能查到哪一天没跑。

这两件事不写进方案，汇总表半年后就会变成一张谁也不敢引用的表。

十、第四条路：分析库或数据仓库，什么时候才值得

分析库和业务库的存法不一样。业务库按行存，适合一笔一笔改；分析库多按列存，适合一次扫很多行、只算少数几列。

它适合数据量真的很大、报表维度很多、多人同时做临时查询的场景。

临时查询就是事先没想到、会上临时提出来的一种看法。比如把华南区近三个月退货最多的十个客户，按业务员排一遍。

代价也实在：多一套系统、多一条同步、要设计表怎么建、要有人会维护。小团队上这套，常见的结果是机器买回来了，报表还是那几张，维护的人先累垮。

一个简单的判断：如果一张汇总表能解决八成报表，先别上分析库。

十一、数据怎么搬过去：批量、实时、两个库同时写

第一条，批量同步。每天凌晨导一次，简单、便宜、对业务库影响小，代价是只能看到昨天的数。

第二条，实时同步。订阅数据库的变更日志，把每一行改动当成一条消息送出去。延迟能压到秒级，但要处理重复、顺序和断点续传，出了问题要有人会查。

第三条，两个库同时写。应用写业务库时顺手写一份到分析库。

听起来最直接，实际上最容易出不一致。

十二、两个库同时写，为什么多数团队最后会放弃

第一，所有写入口都要改。订单、退款、客户、商品，漏一处就少一份数据，而且不会报错。

第二，两个库不在一个事务里。事务就是一组要么一起成功、要么一起失败的操作，跨了两个库，这条保证就断了。业务库写成功、分析库写失败，这笔单就只存在于一边；反过来也一样。

要补，就得知道哪一笔没写进去。这要求系统额外记一份日志，等于又多一套要维护的东西。

第三，出了差异要有人比对、有人修。这个人通常不存在。

所以两个库同时写只适合极少量、极稳定的数据。主业务这条线上不要用它。

十三、数据要多新，直接决定花多少钱

第二天早上看昨天，最便宜：一次批量同步，一个定时任务，出错第二天补。

每小时更新，要多一次调度和一轮同步，业务上能接受最多晚一小时。

分钟级或实时，要多一套同步组件、监控和故障处理，成本明显上一个台阶。

先问业务：这个数早一小时看到，能多赚多少，或者少赔多少。答不出来，就选便宜的那一档。

十四、一张表，对号入座

把前面的内容收成一张表，按自己的情况找位置。

你的情况	先选哪条路	主要代价
数据几百万行以内，报表一天几次，能等到第二天	业务库加查询限制	数据长大后会不够用
报表多，随时要查，能接受几秒前的数	只读副本	副本会被大查询拖慢，复制会落后
指标固定，看趋势和排名，能接受隔天或每小时	汇总表	多一套任务，规则变更要重算，补数要有人管
明细几千万行以上，维度多，多人临时查询	分析库或数据仓库	多一套系统、同步、建模和运维人力
月底集中跑，平时很闲	汇总表加低峰跑批	月底仍要盯任务是否跑完

多数公司落在前两行。真正需要第四行的，比想象中少。

十五、迁移顺序：先挪报表，再换存储

迁移顺序比选型更容易出事。稳妥的做法分三步。

第一步，先把报表从业务库挪到副本或汇总表。观察一周，确认下单没有变慢，报表的数也对得上。

第二步，把汇总任务从应用里挪出来，交给独立的调度，配上失败通知和补数办法。

第三步，才考虑换存储、上分析库。到这一步，你已经知道报表到底有多重、数据到底要多新。

每一步都能停，也能退。不要一次把三件事全做完，那样出了问题不知道是哪一步引起的。

十六、上线前要验四件事

数对得上：同一张报表，新旧两条路各跑一次，逐行比。有差异要能解释，不许写一句先不管。

延迟看得见：副本落后多少、汇总任务几点跑完、失败了谁收到通知。三个数都要能在屏幕上看到。

能退回去：把报表改回查业务库要多久，谁有权操作。这两个问题要能当场答出来。

权限收得住：报表账号只能读它该看的表，分析库不要对所有开发人员开放。客户名单和金额，不是谁都该看。

十七、三个自查问题与这一轮的决定

第一，最慢的一张报表跑多久，扫多少行，一天跑几次。答不出具体数，说明还没到选型的时候。

第二，老板要的数晚一小时看到会怎样，晚一天呢。答案决定你该买哪一档新鲜度。

第三，报表系统明天坏掉，下单还能不能照常。如果能，说明两条路已经分开；如果不能，先做这件事。

这一轮的决定可以很短：多数团队第一步不是买数据仓库，是先给报表修一条独立的路。

只读副本加汇总表，通常就能把业务库解放出来。等数据量和查询复杂度真的上来了，再谈分析库。