每到月末或季末，技术群里就会准时出现同样的抱怨："报表又开始跑了，交易响应又变慢了。"报表跑完之后，一切恢复正常，但下个月还会再来一次。
当交易和报表共用同一套数据库，资源竞争几乎是不可避免的。
交易和报表：两种截然不同的工作负载
交易类查询是点查或小范围操作，每次涉及数据量小，要求毫秒级响应。报表类查询需要扫描大量数据，涉及多表关联、聚合计算，单次可能涉及数千万行。这两种工作负载在同一套数据库上运行，就像在同一有限空间内争夺资源。
资源竞争：变慢的直接原因
CPU：报表的聚合计算在抢交易的时间片
GROUP BY、SUM、COUNT 等聚合操作需要大量 CPU。多个报表任务同时执行时，CPU 使用率飙升，交易请求开始排队。对于延迟敏感的交易，几十毫秒的额外延迟可能触发超时重试，进一步加剧压力。
I/O：报表的大范围扫描在挤压交易的缓存空间
报表查询扫描大量数据页，被加载到缓存中后会挤出热数据。交易查询需要的热数据被挤出缓存后，不得不从磁盘重新读取。更严重的是，如果报表触发了全表扫描，大量连续的磁盘读取会直接占满 I/O 带宽，交易的磁盘访问也在排队等待。
连接数：报表任务在占交易的名额
报表工具一个查询占用一个连接，复杂报表套件可能同时发起数十个查询。当连接数接近上限，新的交易请求无法获取连接，只能等待或直接报错。
锁和版本链：长事务对并发的影响
长事务的读可能阻塞其他事务的写操作。即使使用 MVCC，大量长时间运行的读事务也会导致版本链过长，增加垃圾回收压力，间接影响读写性能。
四种应对方式
时间隔离：让报表只在低峰期跑
最简单的做法。适合有明确低峰期、报表时效性要求不高的场景。局限：随着业务增长，低峰期也可能被占满；需要实时数据的产品无法满足需求。
资源隔离：报表走只读从库
利用主从架构，报表走从库，交易走主库。适合已有主从架构、可接受毫秒到秒级延迟的场景。局限：从库硬件资源同样有限，报表量大可能需要多个专用报表从库。
读写分离：中间件自动路由
中间件根据 SQL 类型自动路由，写操作和强一致性读走主库，普通读走从库。适合有成熟中间件的场景。局限：中间件是额外组件，路由规则需持续维护。
HTAP 数据库：交易和报表在同一数据库中运行
HTAP 数据库通过计算与存储分离，配合不同存储引擎服务不同查询。TiDB 和平凯数据库（TiDB 企业版）的架构中，行存引擎（TiKV）负责交易型点查和写入，列存引擎（TiFlash）负责分析型大范围扫描和聚合计算。两种引擎存储同一份数据的不同格式，数据通过内置复制机制自动同步。交易和报表分别由不同引擎处理，资源竞争被数据库内部消化。
适合需要实时报表数据、希望避免维护多套数据库、工作负载持续增长的场景。TiDB 的 TiFlash 列存引擎能够同步复制 TiKV 中的数据，在报表查询时提供列式存储的计算优势，同时保证数据的一致性。
让交易和报表不再打架
无论选择哪种方案，核心原则都是一样的：让不同类型的工作负载使用不同的资源通道。当交易和报表不再挤在同一条路上，变慢的问题自然就消失了。