我们在 Windows 和 Linux 系统上使用 DB2 LUW 10.5 和 11.1，以防它与他的回答相关。
问题：在某个时候使用 4K 而不是 32K 是正确的吗？如果是这样，为什么？（当它可以使用时性能会更好吗？）或者，它只是史前时代的遗留附属物，当时 4K 只是页面大小？
背景：当我创建 DB2 数据库时，我总是只创建一个 4K、8K、16K 和 32K 表空间和关联的缓冲池。
我的经理在这方面向我提出挑战。（对他有好处 - 我应该知道这一点！）他认为我们应该只创建一个 32K 表空间并完成它。
我找不到任何可以告诉我的信息，例如，当行大小允许时，我们应该使用 4K 而不是 32K，因为 XYZ。它告诉我我可以这样做，但不是那样/什么时候应该这样做。
这是一个很好的问题，但遗憾的是，答案值得在一本不存在的书中写一整章。您链接到的 Ember Crooks 文章是一个很好的概述；我将在这里添加一些在决定表空间页面大小时可能需要考虑的随机因素。
TL; 博士。
考虑以下几点，选择一种最适合您的数据的页面大小。如果您的性能测试显示可以通过将某些表移动到具有不同页面大小的表空间来解决问题，请明智地执行此操作。
决定因素。
正如您所提到的，表格行宽决定了容纳它们所需的最小页面大小。尽管您总是想要“适用于您的数据的最小的”，但这并不意味着您总是想要“适用于您的数据的最小的”。
首先，通常的论点“避免不必要的 I/O”和“一次处理更少的数据”与较小的页面大小可能有点错位。如果您的表空间容器位于 ZFS 文件系统上的 LVM 卷上的 VMWare 虚拟磁盘上的 Ceph 卷上的未知数量的可能使用旋转磁盘或 SSD 的 RAID6 设备上，您真的知道您的 4K 有多少物理 I/O （或32K）读请求会引起什么？
如果您的工作负载创建了无法通过其他方式解决的表空间热点（大多数 I/O 请求转到有限数量的页面），那么较小的页面大小肯定会有所帮助。在这种情况下，较小的页面可以提高缓冲池效率并减少代理之间竞争访问同一页面的页面闩锁等待。另一方面，较小的页面大小意味着更长的 LRU 链，因此可能会降低页面清理效率。
也有更大页面大小的论据。
存在 LOB 数据。
通常 LOB 数据存储在表行之外的单独数据结构中，这些数据结构具有以下几个性能缺点：
如果您的大多数 LOB 值都相对较小，并且在给定较大页面大小的情况下可以放入行本身（通常是这种情况），您可以将它们内联存储，从而减轻这些缺点。
压缩。
较大的页面大小提高了自适应（页面级）压缩的效率。通常，数据压缩带来的 I/O 减少超过其 CPU 成本。
不要忘记临时表空间。
即使可以将每个表单独放置到 4K 表空间中，也可能需要具有更大页面大小的系统临时表空间（和相应的缓冲池）。如果查询连接来自两个或多个表的低于 4K 的行，则结果集宽度可能会超过 4K 限制，如果需要溢出，则需要适当大小的表空间。
值得一提的是，“以防万一”创建每个可能页面大小的表空间并不是一个好主意，因为正如您所说，每个都需要一个专用的缓冲池，并且多个缓冲池，除非必要，几乎总是比一个大的。
我终于找到了正确的谷歌搜索，并在 Ember Crooks ( https://datageek.blog/2013/07/09/db2-luw-what-is-a-page/ ) 的一篇帖子中找到了一条注释，上面写着更小页面是 OLTP 或电子商务网站的首选，因此您处理的数据量较小。那我想这就是答案。使用适用于您的数据的最小的，认识到您希望在页面上获得多行。
我将把它留下答案，而不是仅仅删除它，以防其他人来寻找它。
这种选择通常取决于系统中的工作负载类型。简要地：
事务系统通常每个请求通过几条记录读取数据。Db2 中最小的存储块是数据页。要读取单个数据行，Db2 必须从磁盘读取整个数据页。典型请求所需的行通常随机驻留在数据页中，因此，磁盘 IO 的数量接近此类系统中典型查询返回的记录数量并不罕见。因此，每 1 行/IO 读取是 4K 与 32K - 对于较大的页面大小返回相同结果集的更多不必要的 IO。
DSS 系统通常会扫描大量数据——通常每个 IO 请求通过更大的读取可以更有效地完成。