鎖定頁面的性能 v 64 位 SQL2005/2008 上的本機記憶體
我了解在 64 位系統上為容納 SQL2005/2008 服務的服務帳戶設置記憶體中的鎖定頁面使用 AWE API 並有效地阻止 SQL 的緩衝池被分頁到磁碟 - 提高了穩定性。
但是，如果您有一個具有足夠可用記憶體的專用機器，那麼您確信 SQL 不會分頁 - 原生 SQL 64 位記憶體管理是否更快？
簡短的回答是，如果使用得當，Lock Pages In Memory 可以提高 SQL Server 在 64 位系統上的性能。
冗長的答案讓我們後退了幾步。
首先，您需要了解分頁和分頁到磁碟之間是有區別的。在現代作業系統中，所有記憶體都分配在VAS（虛擬地址空間）內的頁面中。這不是一件壞事，這就是它的工作原理。
當不使用 Lock Pages 時，SQL Server 使用緩衝池記憶體的方式存在兩個問題：
首先，分配記憶體的成本更高。當程序啟動或請求更多記憶體時，作業系統會按需為其創建新頁面。因此，通常，當 SQL Server 執行時，它會一直通過與作業系統聊天來請求、獲取、釋放頁面，這很昂貴。
其次，NUMA 不能很好地工作。正確的 NUMA 支持意味著應用程序可以依靠駐留在最接近執行緒所在處理器的物理記憶體中的頁面，但是當作業系統接管分頁時，SQL Server 不能保證這一點。它必須檢查每個頁面請求的 NUMA 駐留，這也很昂貴。
當您啟用記憶體中的鎖定頁面時，SQL Server 不必為緩衝池處理這些問題中的任何一個，因為它使用 AWE API 進行記憶體管理。
首先，當它請求記憶體時，它隻請求一次，並且一次從作業系統獲取一個頁面列表。然後，將來，它可以根據需要分配這些頁面，而無需向作業系統詢問它們。
其次，因為它從作業系統鎖定頁面，它知道這些頁面的屬性不會改變。所以如果該頁是NUMA頁，它會將其放入NUMA Buffer Pool中，而不必擔心下次檢查時驗證它是否在NUMA中。
您會注意到這些改進既隨著數據庫的增加（當記憶體分配發生時），也隨著時間的推移（通常 SQL Server 將與作業系統處理頁面分配/解除分配）。
如果您想了解更多詳細資訊，請參閱Slava Oks 在 SQL Server 團隊中撰寫的一篇關於此的優秀技術文章。他還有一篇關於NUMA 如何在 SQL Server 中工作的精彩文章的問答文章。