复制表可以在任意一个OBServer 节点上提供强一致性读。那一个租户上有多个复制表时，由于提供的强一致性读，会影响数据库性能吗？
会影响数据库性能，但主要体现在写入端；读性能不仅不受影响，反而会显著提升。
性能影响机制
当一个租户上存在多个复制表时，它们会共享同一个广播日志流（Broadcast Log Stream） 。 每次对复制表执行写入操作时，数据变更都需要通过广播日志流同步到租户内所有 OBServer 节点 的副本上。因此，复制表数量增多带来的性能影响主要体现在写入端：
- 写入放大效应 ：一次写入需同步到所有节点，节点越多，写入开销越大。
- 广播日志流压力 ：多个复制表的写入共用同一广播日志流，高频写入时该日志流会成为瓶颈。
- 存储开销增加 ：每个节点都存储一份完整数据，复制表越多，整体存储占用越大。
读性能提升原理
从读取角度看，多个复制表不会降低读性能，反而能显著提升读性能 ：
- 本地化读取 ：每个节点都有完整数据副本，查询无需跨节点网络传输，延迟极低。
- 强一致性读无额外开销 ：由于数据在本地，强一致性读直接在本地完成，无需等待远程节点确认。
- 读并发能力增强 ：所有节点都能提供读服务，天然实现读负载均衡。
最佳实践建议
复制表本质是牺牲少量写入性能，换取极致的读性能 ，适合读多写少 的场景（如参数配置表、字典表、导流表等）。 实际使用中建议：
- 控制数量 ：避免创建过多复制表，仅对确实需要高频本地读取的表启用。
- 控制写入频率 ：复制表不适合高频更新场景，写入越频繁，广播同步开销越大。
- 关注节点规模 ：节点越多，广播同步开销越大，需权衡集群规模与复制表数量。