将大型DB2表拆分为多个表以提高性能是否有意义？

Question

我们目前正在使用OLTP应用程序在DB2数据库中存储信息。 有关声明的信息存储在多个DB2表中，而且有些表非常庞大（2.6亿条记录）。

如果我们想要提高性能，那么复制用于存储声明信息的每个表是有意义的。因此，我们现在有两个表DECLARATION_A和DECLARATION_B，而不是单个表DECLARATION。我们的想法是在DECLARATION_A表中存储与类型A的声明相关的信息，在DECLARATION_B表中存储类型B的声明。

1. 那么这种分裂会改善那些写入和读取这些宣言表的业务流程的性能吗？
2. 或者更具体地说：这种拆分还能确保正在读取的并发业务流程B正在读取/更新/创建类型为A 的声明的记录的业务流程A受到的影响较小 /更新/创建类型为B的声明的记录？

Answer 1

总的来说，我不相信拆分桌子会改善你的表现，我会尝试在高层次上解释原因。如果您将表拆分为A和B，则必须将更新路由到一个并读取另一个。即使通过避免并发读取来加速读取（让我们假设您当前使用悲观锁定协议），然后定期您需要确保将更新传播到读取表（例如，B）来自更新表（例如，A）。之前的操作会产生额外的开销，因此，最终我不希望您的性能得到改善。

此外，DBMS的设计方式是尽可能避免不同内存页面之间的冲突。换句话说，如果您的最新交易正在更新页面X，那么读取交易将受到影响，直到第X页上的锁定被释放。页面X将是最后一页（在仅附加工作负载中）或内存中的多个页面（以随机更新模式），具体取决于您的工作负载。

总之，我认为您需要提供数据库正在使用的锁定机制，以及应用程序的操作配置文件（即SELECT / INSERT / DELETE / UPDATE的百分比）。

Answer 2

取决于。

如果它是OLTP应用程序，则意味着具有记录级别，基于索引的访问的短事务。是否使用相同的硬件和两个争用同一资源的数据库是一个好主意？

如果它是一个凌乱的类似OLTP的系统，并且不确定我们正在做什么，那么重新访问架构和程序并最终按目的/业务应用程序拆分数据可能会很好。