一、內存數據庫出現的背景

　　在傳統的數據庫表中，由于磁盤的物理結構限制，OLTP類操作引起的隨機查找會給IO系統帶來高昂的開銷，因此傳統的表和索引的結構設計為使用B-Tree而盡量減少隨機查找，但由于機械磁盤和數據庫鎖的存在，B-Tree結構在處理大并發的OLTP環境時就顯得非常乏力，雖然有很多辦法來解決這類問題，比如說樂觀并發控制、應用程序緩存、分布式架構等，但采用上述方案會導致修改引用程序，這不僅成本高且風險極大。而隨著這些年硬件的發展，現在服務器擁有幾百G內存并不罕見，此外由于硬件NUMA架構的成熟，也消除了多CPU訪問內存的瓶頸問題，因此具備了使用新方式來處理更大并發和數據量的條件，這種新的方式就是使用內存計算技術。

　　內存的學名叫做Random Access Memory(RAM)，因此如其特性一樣，是隨機訪問的，因此對于內存，隨機查找不會引入額外開銷，使用Hash-Index這樣的數據結構更符合內存的特性，而對應并發的隔離方式也對應的變成了MVCC(多版本并發控制)，從而消除了鎖引入的性能瓶頸。因此內存數據庫可以在同樣的硬件資源下，處理更多的并發和請求，并且不會被鎖阻塞，在SQL Server 2014中，集成了這個強大的內存數據引擎，如果結合SSD AS Buffer Pool特性，所產生的效果將會非常值得期待。

　　二、SQL Server內存數據庫的組成和表現形式

　　在SQL Server 2014的內存數據庫引擎由兩部分組成：內存優化表和本地編譯存儲過程。雖然內存數據庫集成進入關系數據庫引擎，但訪問內存數據庫的方法對于客戶端來說是透明的，這也意味著從客戶端應用程序的角度來看，并不會知道內存數據庫引擎的存在。如圖1所示。

▲圖1.客戶端APP不會感知Hekaton引擎的存在

　　首先內存優化表完全不會再存在鎖的概念(雖然之前的版本有快照隔離這個樂觀并發控制的概念，但快照隔離仍然需要在修改數據的時候加鎖)，此外內存優化表Hash-Index結構使得隨機讀寫的速度極大提高，內存優化表還可以設置為使用非持久化日志，既數據既不寫日志，也不會CheckPoint到磁盤，從而極大的降低了IO壓力(適合于ETL中間結果操作，或者其他允許丟失數據的場景)，這樣一來也可以消除寫日志引入的性能瓶頸。

　　下面來創建一個內存優化表：

　　首先，內存優化表需要數據庫中存在一個特殊的文件組，以供存儲內存優化表的CheckPoint文件，與傳統的mdf或ldf文件不同的是，該文件組是一個目錄而不是一個文件，因為CheckPoint文件只會將新增的數據附加在到新的CheckPoint文件，而不會修改現有的CheckPoint文件，如圖2所示。

▲圖2.內存優化表所需的特殊文件組

　　下面再來看一下內存優化文件組在磁盤系統的存儲形式，如圖3所示。

▲圖3.內存優化文件組

　　創建完內存優化文件組之后，接下來再創建一個內存優化表，如圖4所示。

▲圖4.創建內存優化表

　　目前SSMS還不支持UI界面創建內存優化表，因此只能通過T-SQL來創建內存優化表，如圖5所示。

▲圖5.使用代碼創建內存優化表

　　這里創建一個簡單的內存優化表，這里上述設置Hash Bucket為1024，目前SQL Server 2014還不支持動態的Hash Bucket，因此必須手動設置該值。表中設置了Memory_Optimized為ON意味著表是內存優化表，而Durability設置為Schema_And_Data則意味著內存優化表中數據也是持久化，這意味著除非啟用了SQL Server 2014的延遲寫特性，數據不會由于異常情況導致丟失。

　　當表創建好之后，就可以查詢數據了，值得注意的是，查詢內存優化表需要snapshot隔離等級或者hint，這個隔離等級與快照隔離是不同的，如圖6所示。

▲圖6.查詢內存優化表需要加提示