我们使用在 AIX 上运行的 DB2 LUW（具体来说，我们目前使用的是 9.7 FP4）。
根据 IBM 的最佳实践，他们建议在构建表时将数据、索引和 LOB/LONG 数据分别放入各自的表空间中。（原因是更好地控制磁盘、维护、备份等。）
表空间必须与缓冲池相关联。现在我们的大多数表和索引都适合 4K 缓冲池和表空间。
通常我们的脚本会设置一个 4K 缓冲池 BP4K。然后我们设置至少两个 4K 表空间（因为我们没有很多 LOB）：TS_DAT_4K 用于数据，TS_IND_4K 用于索引。默认情况下，我们刚刚将这两个表空间分配给缓冲池 BP4K。
我想知道的是：既然索引在它们自己的表空间中，是否也应该给它们自己的缓冲池？
我想知道这是基于优化的原因。如果索引有自己的缓冲池，那么它们更有可能保留在内存中（而不是因为表记录被读入而被推出内存）。这将允许更快地扫描索引以查找表中的记录。由于索引将不再与表共享同一个缓冲池，因此现在可以将更多表保留在内存中以进行逻辑检索而不是物理读取。所以我的想法是，这会减少物理 I/O，从而有助于数据库的性能/维护。
我也忍不住想知道这是否只是预优化，这在 99% 的情况下是一件坏事，引入了额外的开销等（特别是因为我们还没有确定我们需要单独的缓冲池关于当前性能。当然，正在开发的应用程序还没有投入生产，仍然需要数据库调整....）
对此有何想法？这是最佳做法吗？或者只是预先优化和过度思考？
让我们并行运行两个假设的数据库（
H1和H2），缓冲池的 RAM 总量相同（R）。H1有一个 size 的缓冲池R。H2有两个缓冲池：一个I用于索引页，另一个D用于数据页。（D+I==R当然。）问题是：
I并D使其H2表现优于H1？我的回答是一般情况下不能。的数据库引擎
H1比H2. 如果一天中的某些时候更多的索引页会带来更好的性能，它可以丢弃未使用的数据页并拥有一个“主要是索引页”缓存。如果稍后，数据页变得更热，它可以驱逐更多索引页并拥有“主要是数据页”缓存。H2不能那样做。一旦它I缓存了页面价值的索引页面，它就无法缓存更多，即使那是现在最好的。它因 RAM 的次优使用而卡在那里。如果最初选择的/ split 是理想的，并且工作负载非常稳定，那么
H2执行的唯一方法就是。这肯定会发生，但我敢打赌这不是一个非常常见的数据库场景。如果这不是您的情况，请考虑与数据和索引页之间缓存的动态分区相同，这些缓存由最了解优化 I/O 的方式（即数据库引擎）直接管理。H1DIH1H2这并不是说维护不同的缓冲池从来都不是一个好主意。
我遇到过的将特定页面隔离在特定缓存中的一种情况是有一个关键的“报告”需要始终（显然）快速运行，并且碰巧使用了一些几乎从未在其他地方使用过的表。因此，这些页面不断被逐出，并且该“报告”的运行时间因运行而异。将一组特定的表（及其索引）移动到特定的池中消除了大部分“非确定性”性能部分。
但这对于整个数据库来说是次优的，更多的是混乱和更接近 Voodoo 优化 IMO。（那不是在 DB2 上，但我相信这与这里无关。）
所以我的建议是：如果您有 X Gb 的 RAM 可用于缓存，请使用单个缓冲区，将所有内容放入其中，让数据库引擎在那里发挥其魔力。
如果您遇到似乎可以从缓存隔离中获益的极端情况，请尝试一下，对其进行基准测试，考虑必须为每个缓存大小维护幻数的开销，然后转而调整查询、模式或磁盘布局:)