SQL2016大幅改善In-Memory OLTP效能，所以我在SQL2016花了很多時間研究、測試並閱讀相關whitepaper，
我也先告訴大家一件事，In-Memory table並非效能萬靈丹，
不要以為把disk-table轉換到in-memory table，現有系統交易效能就可突飛猛進，
而且真實世界要把disk table要轉換in-memory table也非那麼簡單(除非你的disk table layout真的很單純)。
很多人問我，他在開發環境，把現有系統一些Disk table轉為Memory table，
但測試後發現Memory table效能反而比較慢，這是SQL2016的bug嗎?還是記憶體有需要什麼特殊規格才能有所優化呢?
我整理一下我如何測試Memory table效能
多核心多執行緒
你永遠要記得In-Memory是設計再多核心多執行緒的併發負載，
如果你只使用單一執行緒或單一CPU進行POC，那麼你永遠不可能享受到In-Memory所帶來的效能改善。
測試工具造成的latency
SQLQueryStress.exe 和 Ostress.exe是我很常用來模擬多人(多執行緒)對In-Memory進行測試的工具，
但要注意Ostress.exe預設會將Ostress.exe結果輸出並寫入disk(o參數可以指定目錄)，
這過程會造成硬碟高度latency，所以會產生in-memory效能和disk table相同的錯誤結果(甚至更糟的效能結果)，
所以我會建立一個RAMDSIK來消除disk的latency，以免再次錯怪in-memory。
ostress.exe -S"RICONB\SQL2K16" -E -d"mymemoryDB" –Q"SELECT * from rsa241" -n10 –r10 –oX:\ramdisk\benchmarklog
Native Compilation只對複雜查詢邏輯有效
簡單的查詢(select top 100 * from taba)使用Native Compilation完全沒幫助，效能甚至比disk table更糟，
所以別拿簡單查詢來測試，然後說In-Memory對效能更本沒幫助。
程式處理特性
如果你的程式都是先取得大量資料後處理，列如client發送訊息給sql server，sql server返回50萬筆資料，
無論這些資料是從disk table或in-memory table，你依然還是得傳送50萬筆資料給client，
這樣的程式處理特性，永遠不可能從in-memory table獲得任何效能效益。
結論
如果你正有在打算使用in-memory 來改善效能，我會建議一定要完整複製生產環境的資料量，
先使用disk table執行一次，然後轉換至in-memory table(建議先把disk table 相依物件釐清)在執行一次後，比較兩者結果，
雖然in-memory table消除latch/lock，但你應該會發現使用in-memory所產生新的bottleneck~~~~~good luck。
參考
[SQL SERVER]SQL2016-掌握SQL Server Function 效能
重新執行的標記語言 (RML) 公用程式的 SQL Server 的描述
SQL SERVER – Download RML Utilities for SQL Server
