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

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

很多人都問對于他們的工作量和環境，切換到SQL Server 2014是否有意義?；谖业慕ㄗh，他們會做出持續至少5年的決定。因此這里我有巨大的責任。我要確保不會建議不能100%融入他們環境的技術。遺憾的是內存中OLTP不能融入99%的所有環境。

因此內存中OLTP有問題么，是什么我還不能推薦它給用戶呢？我們開始分析……

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

這是不行的，因為內存中OLTP當前不支持外鍵（foreign keys）。非常希望你的數據庫設計有引用完整性（referential integrity）。如果不是的話，請回到數據庫基礎設計，了解下引用完整性。這已是很多用戶已經經歷的最常見中斷切換之一。他們喜歡遷移一些表到內存中OLTP，但他們不喜歡用它來丟失他們的引用完整性……

現在假設你同意在自己的表上不使用外鍵，你已經遷移它們到內存中OLTP。到目前還好。在你的內存優化表上如何處理架構修改呢？任何ALTER TABLE語句不被支持，你不能稍后創建任何額外可能需要的索引（哈?；蚍秶饕?。當創建1個哈希索引，在表創建期間，你需要指定桶數。

這意味著你需要保護你的數據增長，還有隨著時間過去你的數據如何改變。當你以后想要修改你的哈希桶數，因為你已意識到你有大量的哈希碰撞，你必須刪掉你的內存優化表，然后再次重建。同時你如何處理你的數據？你必須轉移它到另一個表，這樣的話你不會丟失數據。這時你把數據存在哪里呢？用戶如果這時還要訪問這些數據怎么辦？有很多的問題，但沒有真正有用的答案……

好，現在你用內存優化表很好，現在你想使用存儲過程的本地編譯功能。哇哦，現在好戲才開始！本地編譯存儲過程真的，真的非?？欤驗槟阌帽镜貦C器碼執行——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內部運行業務邏輯。

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

人們會問我，為什么我對這個驚艷的新技術如此否定。不是的，我并非否定，我只想告訴你事情的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/