SQL server 在記憶體表中的表現
我正在使用 Microsft SQL Server 2016。我有一個包含 140000 行的 SQL 表。它僅用於選擇數據。
我試圖通過使其成為 In-Memory 表來提高它的選擇性能（值得一提的是，這是我第一次使用 In-Memory 表）。
我在 SQL Server Profiler 中得到的結果相當不滿意。比較“CPU”、“Reads”和“Duration”列的數據：從 In-Memory 表中 SELECT 的“CPU”稍高，“Reads”低 10 倍，但不幸的是“Duration”幾乎保持不變。
我嘗試生成記憶體中 OLTP 遷移清單 - 結果是成功的。
您能否告訴我這是否是對 SQL Server In-Memory 表的良好使用？
也許我做錯了什麼，因為持續時間保持不變？
先感謝您！
記憶體優化表上的 SELECT 在 SQL 2016 中不是單執行緒的（但在 2014 年確實如此）。
所以：
- 使用單執行緒測試磁碟和記憶體中的性能不是有效的概念證明。
- In-Memory OLTP 並非旨在加快查詢速度 - 它旨在利用現代硬體並擴展寫入工作負載。
- 正如您已經證明的那樣，對於大量列，我希望選擇列的子集會更快。
這裡真正的問題是您的工作負載是否可以從 In-Memory OLTP 中受益，以及您是否可以權衡取捨。並保證在測試時執行分析器會扭曲您的結果。我不會使用分析器，我只會使用
SET STATISTICS TIME ON.我不希望觸及記憶體優化表與磁碟表的 SELECT 語句的性能顯著提高（或任何提高）。唯一可能的例外是，如果您在記憶體優化表上使用列儲存索引，而不是對磁碟表使用列儲存索引，並且您有分析查詢（但這並不是一個真正公平的比較，而且 in-mem CCI 也很輕比磁碟 CCI 落後幾年）。
但是，如果您的查詢速度要慢 10 倍，則表明索引和/或您的查詢有問題。
我也不明白讀取速度如何慢 10 倍，但“持續時間”保持不變。可以使用一些清晰度。
您注意到您使用的是 MS SQL Server 2016，SP1。自 SP1 以來已經發布了 5 個 CU，我強烈建議您修補到最新的 CU。在此過程中修復了許多記憶體中的錯誤。
如果您正在做分析索引，我認為沒有理由使用 HASH 索引。它們被廣泛誤解，對於涉及多於一行的查詢毫無用處，它們的細微差別可能導致未受過教育的人準確地看到您正在經歷的性能下降。一個範例是有一個多鍵列，但僅引用查詢中的前導列。這將對磁碟表使用 SEEK，但會為記憶體優化表生成表 SCAN。
您連結到的部落格似乎正在執行單執行緒 POC，這對於記憶體中 OLTP 也毫無意義，因為它旨在擴展寫入密集型和/或高並發工作負載。
同意其他人的觀點，為了真正提供幫助，我們必須看到 DDL 和 DML。