报表查询走不走 OLTP 库？我们把这条边界画在哪

背景

做了 3 年大数据平台，最近半年在不同团队里反复撞同一个问题：业务方说「就一个 select count(*)，跑在主库上 200ms 就完了」，DBA 说「主库是交易的命脉，报表这种长 SQL 进来就是灾难」。争论到最后往往不是技术输了，而是「谁先扛不住」输了——要么报表拖垮了交易，要么交易告警把报表账号直接 ban 了。今天想把这个边界摊开聊聊，因为我发现三个团队的画法完全不一样，没有「标准答案」。

常见分歧（我在三个团队见过三种做法）

1. 主库扛派：报表 SQL 走主库，简单直接，没有主从延迟问题，业务方体验最好。代价是长查询 / 大扫描会把 buffer pool 打穿、把连接池占满，一次 P99 抖动就是事故，而且事故一定发生在流量最高的时候。
2. 只读副本扛派：读写分离，报表走从库，主库专心交易。代价是主从延迟（尤其大事务 / 长 DDL 之后），业务方会看到「我刚下单怎么查不到」；而且报表一多，从库反而成了新的瓶颈，最后还是要回到「升配 vs 分流」的老问题。
3. 数仓扛派：走 CDC → Kafka → ClickHouse / Doris，主库一个报表查询都不接。代价是链路长、延迟分钟级、字段口径经常对不齐，业务方每次都要问「为什么我看到的和库里不一样」，数据团队被追着对齐口径能追到怀疑人生。

我的倾向（说下理由）

• 默认走数仓，但给业务方一个明确的 SLA：T+1 明细 + 5 分钟级实时，写进接口文档，而不是口头承诺；
• 只留一条窄口子：单表、走主键 / 唯一索引、扫描行数 ≤ 1 万、执行时间 ≤ 200ms 的「准实时核对查询」允许走只读副本，且必须用独立只读账号 + max_execution_time 硬限 + 慢日志单独打点；
• 主库对报表一律 0 容忍，哪怕它只是 select count(*)。理由很朴素：count(*) 在 InnoDB 上就是全索引扫描，8 亿行的表一次能跑 30s+，buffer pool 直接被冲，交易 P99 立刻抬头——这不是「会不会出问题」的问题，是「什么时候出问题」的问题。

这条线我理解本质不是「能不能扛」，而是「允不允许」：能扛 ≠ 该扛，一次侥幸扛过去了，下一次流量翻倍就是事故。

想听大家

• 你们团队是怎么划这条线的？是按「能不能扛」还是按「允不允许」？有没有明确写进团队规约？
• 数仓延迟到底能接受到什么程度？业务方真的接受「5 分钟延迟」吗，还是嘴上接受、身体诚实？
• 有没有人走过「主库扛报表」的路子，后来怎么收场的？是被动切到数仓，还是主动治理下来的？
• 只读副本扛报表时，主从延迟你们是怎么兜底的——半同步？GTID 位点对账？还是干脆接受？

欢迎把你团队的边界、踩过的坑、甚至「我们就是扛在主库上，没出事」都贴上来，想看看大家到底是怎么在业务压力和稳定性之间做取舍的。