記憶體優化表——它們真的很難維護嗎？
我正在研究從 MS SQL 2012 升級到 2014 的好處。SQL 2014 的一大賣點是記憶體優化表，這顯然使查詢速度超快。
我發現記憶體優化表有一些限制，例如：
- 沒有
(max)大小的欄位- 每行最大約 1KB
- 沒有
timestamp欄位- 沒有計算列
- 沒有
UNIQUE限制這些都算作滋擾，但如果我真的想解決它們以獲得性能優勢，我可以製定一個計劃。
真正的問題在於您無法執行語句，並且每次您將欄位添加到索引列表中時
ALTER TABLE，您都必須經歷這個繁瑣的過程。INCLUDE此外，您似乎必須將使用者關閉系統才能對實時數據庫上的 MO 表進行任何模式更改。我覺得這完全令人髮指，以至於我實際上無法相信微軟會在這個功能上投入如此多的開發資金，卻讓它變得如此不切實際。這使我得出結論，我一定是弄錯了。我一定誤解了關於記憶體優化表的一些東西，這使我相信維護它們比實際情況要困難得多。
那麼，我誤解了什麼？你用過MO表嗎？是否有某種秘密開關或過程使它們易於使用和維護？
不，記憶體中真的是這樣粗糙的。如果你熟悉敏捷，你就會知道“最小可傳遞產品”的概念；記憶體中就是這樣。我覺得 MS 需要對 SAP 的 Hana 及其同類產品做出回應。這是他們可以在 2014 年發布的時間範圍內調試的內容。
與記憶體中的其他任何東西一樣，它也有與之相關的成本和收益。主要好處是可以實現的吞吐量。正如您所提到的，其中一項成本是變更管理的成本。在我看來，這並沒有使它成為無用的產品，它只是減少了它將提供淨收益的案例數量。正如列儲存索引現在可以更新並且可以過濾索引一樣，我毫不懷疑記憶體中的功能將在即將發布的版本中得到改進。
SQL Server 2016 現已正式發布。正如我所想的那樣，記憶體中 OLTP已收到許多增強功能。大多數更改實現了傳統表格已經享受了一段時間的功能。我的猜測是，記憶體表和傳統表的未來功能將同時發布。臨時表就是一個例子。此版本中的新增功能受記憶體表和基於磁碟的表的支持。