在記憶體表與臨時表中 - 如果 temdb 已經在 ram 磁碟上，則將受益
在docs中，我們提供瞭如何用記憶體表替換臨時表的範例，因為記憶體優化表：
- 僅儲存在記憶體中，並且在磁碟上沒有組件
- 不涉及 IO 活動
- 不涉及 tempdb 使用或爭用
他們說：
記憶體優化導致速度提高，通常快 10 倍或更多。
我想知道我們的系統是否已經將 ram 用於 tempdb 數據庫，哪些好處仍然適用？我猜他們正在硬碟驅動器或 ssd 上測試 temdb 並且懷疑獲得如此好的結果。
更多細節。系統最常用的表變數函式之一是計算對特定實體的訪問。然後，將結果連接到各個表以獲取請求數據。為了優化後面的連接，我將此函式的結果儲存在臨時表中，結果很好。
但是對於非常大的數據量（例如，當函式返回 1-2 百萬個實體時），函式本身的執行速度很慢（這也是正常的，因為我們在表變數中插入了這麼多行）。
所以，我正在考慮將此函式重寫為儲存過程並將實體插入記憶體表中，希望對錶的 CRUD 操作能夠
10 times faster or more。
在Ned Otter的評論中：
如果瓶頸是由於 tembdb 中系統表的鎖定/阻塞造成的，那麼我想將它放在 RAM 中不會有太大的不同。
如果您目前的工作負載因內部組件的爭用而變慢，那麼將 tempdb 放在 ramdisk 上將無濟於事。這是因為問題與 I/O 吞吐量無關。查看 Paul Randal 關於該主題的詳細文章：
意外 DBA（第 27 天，共 30 天）：故障排除：Tempdb 爭用
Tempdb 爭用是指執行緒試圖訪問記憶體中的分配頁面的瓶頸；它與 I/O 無關。
內德繼續說道：
這就是 SQL 2019 支持記憶體優化版本 tempdb 的原因。
這是 2019 年的一項新功能，旨在幫助解決這些類型的爭用問題。您可以在 Erik Darling 的部落格上看到有關這如何提供幫助的展示，以及它如何在 SQL Server 2019 的目前預覽版中尚未準備好：
您確實需要衡量減速是由於 I/O 還是由於爭用。使用上面 Paul Randal 的文章進行深入研究。
由於您更新了問題以提及緩慢的情況是當您將數百萬行插入表變數時，我假設上述爭用不太可能是您的問題（除非您從一次有許多不同的連接）。在這種情況下，ramdisk 方法肯定會有所幫助。
在您對問題的最後更新中，您說：
似乎記憶體計劃表不支持並行計劃（至少在插入時），所以我沒有優化任何東西
這是記憶體中 OLTP 的一個眾所周知的“問題”。您需要通過從多個連接將數據載入到記憶體表中來“滾動您自己的”，而不是使用內置的並行性。