SQL Server 數據壓縮絕對適用於只讀數據庫嗎？
我讀到的一些關於 SQL Server 數據壓縮的文獻表明，寫入成本增加到通常所需的四倍左右。這似乎也暗示這是數據壓縮的主要缺點，強烈暗示對於只讀存檔數據庫，使用 100% 填充頁面的數據壓縮將提高性能（幾乎沒有例外）。
- 上面的陳述是真的嗎？
- 數據壓縮和其他（用於閱讀）之間的主要“變化”是什麼
- “CPU + x%”？
- “IO -y%”？
- 出現分頁？
- 臨時數據庫的使用？
- 記憶體使用情況？
- 而寫作呢？
***出於此問題的目的，您可以將上下文限制為大型（> 1TB）***數據庫的 PAGE 級壓縮，但始終歡迎提供其他評論。
參考：
SQL Server 儲存引擎部落格（DW 場景顯示壓縮非常有利）
決定壓縮什麼的更詳細方法涉及分析每個表和索引的工作負載特徵。它基於以下兩個指標：
U：特定表、索引或分區上的更新操作相對於該對像上的總操作的百分比。U 的值越低（即不經常更新的表、索引或分區），它就越適合進行頁面壓縮。
S：表、索引或分區上的掃描操作相對於該對像上的總操作的百分比。S 的值越高（即大部分掃描的表、索引或分區），它就越適合進行頁面壓縮。
以上兩者都明顯偏向於為 DW 風格的數據庫推薦頁面壓縮（讀取密集/獨占，大數據操作）。
只是我自己在 1-2 年的硬體上進行的實驗所得的 2 美分：
頁面壓縮表（~80 行/頁）上的只讀操作（DW 樣式掃描、排序等）我發現在壓縮大小減少約 3 倍時達到收支平衡。
即，如果表無論如何都適合記憶體，頁面壓縮僅在數據大小縮小超過 3 倍時才會提高性能。您在記憶體中掃描的頁面較少，但掃描每一頁需要更長的時間。
我想如果您的計劃是嵌套循環和搜尋繁重，您的里程可能會有所不同。其中，這也取決於硬體（外部 NUMA 節點訪問懲罰、記憶體速度等）。
以上只是我遵循的粗略經驗法則，基於我自己在自己的硬體（Dell Poweredge 910 和更年輕）上使用自己的查詢執行的測試。這不是福音啊！
***編輯：***昨天，Thomas Kejser 出色的 SQLBits XI 展示文稿作為影片提供。與這個討論非常相關，它顯示了頁面壓縮的 CPU 成本“醜陋”的一面——更新速度減慢了 4 倍，鎖定時間更長。
然而，Thomas 正在使用 FusionIO 儲存，他選擇了一個僅“剛好”符合頁面壓縮條件的表。如果儲存在典型的 SAN 上，並且數據使用 3x-4x 壓縮，那麼情況可能就不那麼引人注目了。
我可以從我的數據倉庫環境中添加幾句話。
在具有 3000 萬行 (18GB) 的測試表上實施壓縮（在我的例子中為 PAGE）將表的大小從 18GB 減少到 3GB！（儲存效率肯定），但將載入時間（寫入）從 22 分鐘增加到 36 分鐘。
因此，對於讀取或讀取數據並將數據放入記憶體中，這可能是一個很好的解決方案，但對於日常數據載入，它可能會導致性能下降。