在 DB2 LUW 中，我什麼時候應該使用 4K、8K 或 16K 表空間，而不是僅僅創建一個 32K 表空間並完成它？
我們在 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 沒有載入到緩衝池中，重複訪問相同的數據會導致重複的直接讀取請求。
- 即使啟用了表壓縮，它們也不會被壓縮。
如果您的大多數 LOB 值都相對較小，並且在較大的頁面大小（通常是這種情況）下可以放入行本身，您可以將它們內聯儲存，從而減輕這些缺點。
壓縮。
較大的頁面大小提高了自適應（頁面級）壓縮的效率。通常，數據壓縮帶來的 I/O 減少超過其 CPU 成本。
不要忘記臨時表空間。
即使可以將每個表單獨放入 4K 表空間，也可能需要具有更大頁面大小的系統臨時表空間（和相應的緩衝池）。如果查詢連接來自兩個或更多表的低於 4K 的行，則結果集寬度可能會超過 4K 限制，如果需要溢出，則需要適當大小的表空間。
值得一提的是，“以防萬一”創建每個可能頁面大小的表空間並不是一個好主意，因為正如您所說，每個都需要一個專用的緩衝池，並且多個緩衝池，除非必要，幾乎總是比一個大的。