交易需要快，报表需要全。这两件事放在同一套数据库里做，要么交易被报表拖慢，要么报表因为资源限制跑不出结果。分开做，又面临数据延迟、运维成本和架构复杂度的挑战。
面对"既要跑交易又要跑报表"的需求，市面上有几种主流架构方案。每种方案都有自己的适用场景和代价，没有放之四海而皆准的最优解。
方案一：单库方案——最简单的起步方式
交易和报表都在同一个数据库实例上运行。报表任务通过时间窗口控制（比如只在低峰期执行），或者由数据库的资源管控机制限制其资源占用。
优点： 架构最简单，不需要额外的组件或数据同步机制。数据天然一致，不存在延迟问题。开发和运维成本低。
代价： 当报表和交易同时运行时，资源竞争难以避免。随着数据量和查询复杂度增长，单库方案会越来越吃力。
适合谁： 数据量较小（TB 级以内）、报表需求简单、业务增长平稳的早期阶段团队。
什么时候该考虑升级： 交易响应开始因报表任务而明显变慢；报表需要的计算资源超出单机能承受的范围；业务对数据时效性的要求提升到"小时级"甚至更高。
方案二：读写分离（主从架构）——成熟可靠的主流方案
交易写入和强一致性读走主库，报表和普通读走只读从库。
优点： 方案成熟，技术生态完善。交易的资源得到保护。
代价： 从库数据天然落后于主库，复制延迟在正常情况下可控，但写入压力大时可能飙升。
适合谁： 中等规模业务，对数据时效性容忍度在秒级以内，报表查询不算特别复杂。
方案三：交易库 + 独立分析库——彻底隔离的重型方案
交易库专门负责在线交易，独立部署数据仓库或数据湖承接报表和分析需求，通过 ETL 管道连接。
优点： 交易和分析完全隔离，分析库可以针对报表场景做专门优化（列式存储、物化视图、预计算）。
代价： 架构复杂度高，数据延迟通常在小时级到天级，ETL 开发和运维是持续成本。
适合谁： 分析需求复杂、对时效性要求不高（T+1 可接受）、有专门的数据工程团队。
方案四：HTAP 数据库——交易和分析合二为一
行存引擎优化交易，列存引擎优化分析，两种引擎存储同一份数据的不同格式，通过内置机制自动同步。
优点： 数据天然一致，不存在同步延迟。不需要搭建独立分析库和 ETL 管道。行列引擎各自优化各自擅长的查询类型。
代价： HTAP 是相对较新的方向，行列混合存储占用更多空间，不同产品的同步延迟和复杂 SQL 支持有差异。
适合谁： 交易和分析负载都强、对时效性要求高、希望避免维护两套系统、业务处于快速增长期。
TiDB 和 平凯数据库（TiDB 企业版） 是 HTAP 方向的典型代表之一，通过 TiKV 行存引擎和 TiFlash 列存引擎的组合，在同一数据库中同时服务交易和分析查询。
五步决策框架
- 看数据量： TB 级以内且平稳 → 单库。超 TB 且持续增长 → 读写分离或更复杂方案。
- 看报表复杂度： 简单汇总 → 从库够用。多维分析/大数据量扫描 → 独立分析库或 HTAP 列存引擎。
- 看数据时效性： T+1 → 独立分析库+ETL。小时级 → 缩短 ETL 或实时管道。秒/毫秒级 → HTAP。
- 看团队能力： 团队小 → 架构简单的方案。有数据工程团队 → 独立分析库。
- 看发展趋势： 交易和分析需求都快速增长 → 选一个能同时支撑两种负载且具备弹性的架构。
没有完美的架构，只有合适的选择
架构选型不需要一步到位，但需要提前思考：当前方案的天花板在哪里？当业务增长到什么程度，就需要开始评估下一个方案？带着这些问题的意识去选，比等到系统撑不住了再仓促切换要从容得多。