我了解在 64 位系统上为容纳 SQL2005/2008 服务的服务帐户设置内存中的锁定页面使用 AWE API 并有效地阻止 SQL 的缓冲池被分页到磁盘 - 提高了稳定性。
但是，如果您有一个具有足够可用内存的专用机器，那么您确信 SQL 不会分页 - 原生 SQL 64 位内存管理是否更快？
AskOverflow.Dev
我了解在 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 中工作的精彩文章的问答帖子。
正如我从与 SQL Server 产品团队的对话中了解到的内存中的锁定页面设置一样，此设置唯一控制的是它允许 SQL Server 忽略操作系统指令，将所有数据分页到磁盘并刷新内存。
在正常情况下，禁用内存中的锁定页面设置不会对您有任何好处或坏处。在内存中锁定页面会帮助您，这是一种奇怪的情况。例如，Windows 2003 RTM 中存在一个错误，当运行 SQL Server 并在服务器上启动远程桌面会话时，操作系统会告诉 SQL Server 无缘无故地将所有内存刷新到磁盘。如果您启用了 Lock Pages in Memory 设置，您的 SQL Server 将忽略此指令，如果您没有设置此设置，那么您的 SQL Server 将按照说明将其缓冲区缓存刷新到磁盘。
还有其他 RAID 驱动程序和 HBA 驱动器存在导致相同问题的错误的情况。
我在这里谈论这个，SQL Server 团队的 Bob Ward 在这里谈论它。
根据我的经验，任何性能提升都会被有一天这会咬你的问题所抵消。我想说的是，如果您的数据增长相对较慢且数据库代码更改很少，那么您可以有效地实现这一点并获得一点好处。但是，如果您的数据库被大量使用并且有时会出现 sql 页面，我会说不要打开它。正如 Ask the Performance Team文章所述：
我还没有找到理由在我的任何系统上打开它