為什麼我還不推薦記憶體中OLTP給使用者

嗯，有些人在看玩這篇文章後會恨我，但我還是要說。1個月來我在記憶體中OLTP這個裡領域裡做了大量的工作，很多使用者都請求使用這個驚豔的新技術。遺憾的是，關于記憶體中OLTP沒有一個是真的令人激動的——看完你就知道了。

記憶體中OLTP有問題麼？

沒有！真的！我喜歡這個驚豔的新技術，但我還不能推薦它給任何使用者。就這樣！很有使用者現在還運作在SQL Server 2008（R2）上，他們就想遷移到SQL Server 2014上。這個驚豔新技術給他們100倍的吞吐量提升。是以讓我們來用它吧！遺憾的是并不簡單。

很多人都問對于他們的工作量和環境，切換到SQL Server 2014是否有意義。基于我的建議，他們會做出持續至少5年的決定。是以這裡我有巨大的責任。我要確定不會建議不能100%融入他們環境的技術。遺憾的是記憶體中OLTP不能融入99%的所有環境。

是以記憶體中OLTP有問題麼，是什麼我還不能推薦它給使用者呢？我們開始分析……

沒有外鍵

當微軟首次向公衆展示記憶體中OLTP時，它是很驚豔的：你切換開關，然後你的工作吞吐量就會快100倍。你隻記住了立即走向右手邊的針，不是麼？但事實完全不一樣。假設你有一個現存的資料庫，你想要移動它的一些表到記憶體中OLTP。

這是不行的，因為記憶體中OLTP目前不支援外鍵（foreign keys）。非常希望你的資料庫設計有引用完整性（referential integrity）。如果不是的話，請回到資料庫基礎設計，了解下引用完整性。這已是很多使用者已經經曆的最常見中斷切換之一。他們喜歡遷移一些表到記憶體中OLTP，但他們不喜歡用它來丢失他們的引用完整性……

不能修改資料庫架構

現在假設你同意在自己的表上不使用外鍵，你已經遷移它們到記憶體中OLTP。到目前還好。在你的記憶體優化表上如何處理架構修改呢？任何ALTER TABLE語句不被支援，你不能稍後建立任何額外可能需要的索引（哈希或範圍索引）。當建立1個哈希索引，在表建立期間，你需要指定桶數。

這意味着你需要保護你的資料增長，還有随着時間過去你的資料如何改變。當你以後想要修改你的哈希桶數，因為你已意識到你有大量的哈希碰撞，你必須删掉你的記憶體優化表，然後再次重建。同時你如何處理你的資料？你必須轉移它到另一個表，這樣的話你不會丢失資料。這時你把資料存在哪裡呢？使用者如果這時還要通路這些資料怎麼辦？有很多的問題，但沒有真正有用的答案……

沒有執行計劃

好，現在你用記憶體優化表很好，現在你想使用存儲過程的本地編譯功能。哇哦，現在好戲才開始！本地編譯存儲過程真的，真的非常快，因為你用本地機器碼執行——C代碼編譯成彙編指令！太棒了！但是在查詢執行期間是沒有執行計劃的，因為你隻執行彙指令，不再執行那些傳統緩慢解釋後的執行計劃。

當你執行遇到問題時，你怎麼辦？你不能看實際執行計劃來認出問題。SQL Server隻提供你估計計劃，但估計計劃不告訴你任何真實資訊。它隻是個估計，沒别的。你真的想鑽研生成的C代碼來找出為什麼本地編譯存儲過程這麼慢？我不這麼認為。

沒有重編譯

除了沒有實際執行計劃外，也沒有重編譯。但你的資料分布改變時，你還是用同樣編譯的執行計劃。在執行期間本地編譯存儲過程不能重編譯。我說過，在運作期間你隻執行彙編指令——它們不能被重編譯。

你如何擺脫這個問題？删除并重建你的存儲過程，因為ALTER PROCEDURE語句不被支援。當你删除你的存儲過程，你也會丢失所有授予的安全許可。你真的想丢失它們？另外，你的本地編譯存儲過程必須用SCHEMABINDING建立。是以當你已經删除存儲過程本身時，你才可以删除你的記憶體優化表（例如，當你想修改哈希桶數時）。偶滴神啊……

本地編譯的業務邏輯

這是我喜歡之一：在用本地編譯的存儲過程裡運作複雜的CPU密集的業務邏輯。哇噢，我喜歡你有的那個大錢包！在SQL Server裡運作複雜的CPU密集的業務邏輯是你可以有的最昂貴想法之一。在企業版SQL Server裡，SQL Server是以每核心7000刀授權。因為我不想在SQL Server裡運作任何CPU密集的工作！那一點也不經濟。當然從微軟角度來說這個很有意義。

如果在SQL Server裡你有一些複雜CPU密集的業務邏輯，把它移到應用伺服器（例如，Web伺服器），因為1個應用伺服器授權是完全不同的——非常便宜。你主要會有架構問題，沒别的。我從不在SQL Server内部運作業務邏輯。

“對于每個人，640K應該足夠了”

哈哈，那是我計算機發展史裡最喜歡的名言之一。遺憾的是他說錯了，當你看這篇文章時，看看用的電腦硬體時就會發現。當你使用記憶體中OLTP時，你需要大量的記憶體。微軟建議記憶體大小為你記憶體優化表大小的2倍，例如對于150GB大小的表，你需要300GB的記憶體。另外的記憶體用做記憶體中OLTP記憶體使用的行版本控制。現在假設下，當你删除你的表，同時你想轉移資料到另一個記憶體優化表：在這個情況下你應該有近600GB的記憶體！準備好了麼？

關于OLTP

人們會問我，為什麼我對這個驚豔的新技術如此否定。不是的，我并非否定，我隻想告訴你事情的2面性，這樣的話你可以做出正确的決定。

另外一些人告訴我記憶體中OLTP如此酷，因為它可以用作ETL過程裡的分段表（staging table），并且我們不需要SQL Server裡的臨時表。哎呦！我們在慢慢拼寫下這個技術的名稱——非常慢：記憶體中O-L-T-P！它是關于OLTP——線上事務處理（Online Transaction Processing）。當然在其它場景也可以使用，但主焦點應該是OLTP場景！好好考慮下它。如果你目前有臨時表的問題，那就在工作量上下文章，嘗試在你臨時表上減少工作量的壓力。在性能調優裡我經常提到：我們的終極目标是解決潛在的問題根源，不是為它建立一個解決方案。（例如當你看到 CXPACKET等待時，設定 MAXDOP為1即可）

小結

記憶體中OLTP是個驚豔的新技術。但目前隻實作了雛形。有太多的限制剛好阻止了大量人們在生産環境中使用它。在這篇文章裡我已經概括了這些限制中的部分，這樣的話你就可以重新考慮下是否想把記憶體中OLTP引入你的特定場景。

我很期待在SQL Server裡的下個版本再次讨論這個話題，在一個圖表裡剔除那些無關的條目，因為微軟已經移除了這些限制。這個驚豔技術還是由微軟來決定往前發展的！

感謝關注！

參考文章：

https://www.sqlpassion.at/archive/2015/03/11/dont-yet-recommend-memory-oltp-customers/

注：此文章為

WoodyTu

學習MS SQL技術，收集整理相關文檔撰寫，歡迎轉載，請在文章頁面明顯位置給出此文連結！

若您覺得這篇文章還不錯請點選下右下角的推薦，有了您的支援才能激發作者更大的寫作熱情，非常感謝！