据我所知，设置在64位系统上的SQL2005 / 2008服务的服务帐户的内存特权的锁页面使用AWE API，并有效地阻止SQL的缓冲池被分页到磁盘 – 提高稳定性。
但是如果你有一个足够的可用内存的专用盒子，所以你确信SQL不会页面 – 是原生SQL 64位内存pipe理更快？
简短的回答是，如果使用正确 ，“locking页面内存”可以增强64位系统上的SQL Server性能。
漫长的回答让我们退后一步。
首先，你需要明白分页和分页到磁盘是有区别的。 使用现代操作系统， 所有内存都在 VAS （虚拟地址空间） 中分页 。 这不是一件坏事，这是如何工作的。
当不使用locking页面时，SQL Server与缓冲池内存的工作方式有两个问题 ：
首先， 分配内存比较昂贵 。 当进程启动或要求更多内存时，操作系统会根据需要为其创build新的页面。 所以，一般来说，在SQL Server运行的时候，它会一直请求，获取，通过与操作系统聊天来释放页面，这很昂贵。
其次，NUMA不能很好地工作。 正确的NUMA支持意味着应用程序可以指向驻留在离线程处理器最近的物理内存中的页面，但是当操作系统正在接pipe分页时，SQL Server不能保证这一点。 它必须检查每个页面请求的NUMA驻留，这也是昂贵的 。
在内存中启用locking页时，SQL Server不必处理缓冲池的这些问题之一，因为它使用AWE API进行内存pipe理。
首先，当它要求内存时， 它只做一次 ，并从操作系统中一次获得一个页面列表。 然后，将来可以根据需要分配这些页面，而无需向操作系统请求。
其次，因为它locking了操作系统的页面，所以它知道这些页面的属性不会改变 。 所以如果这个页面是一个NUMA页面，它将把它放到NUMA缓冲池中，而不必担心下一次检查时它是否在NUMA中。
随着数据库的发展（当内存分配发生时），以及随着时间的推移（通常SQL Server将处理页面分配/重新分配的操作系统），您将注意到这些改进。
如果你想了解更多的细节，Slava Oks在SQL Server团队中有一篇很好的技术文章 。 他还有关于NUMA如何在SQL Server中工作的另一篇精彩文章的问题解答 。
正如我理解我与SQL Server产品团队的对话中的locking页面内存设置一样，这个设置控制的唯一的事情是它允许SQL Server忽略操作系统的指令，将所有数据分页到磁盘并刷新内存。
在正常情况下，禁用的内存设置中的locking页面不会对您做任何好事或坏事。 这是奇怪的事情，在内存中的locking页面将帮助你。 一个例子就是Windows 2003 RTM中存在一个错误，当运行SQL Server并且启动一个到服务器上的远程桌面会话时，操作系统会告诉SQL Server将所有内存无缘无故地刷新到磁盘。 如果启用了“启用内存locking”设置，则SQL Server将忽略此指令，如果您没有设置此设置，则SQL Server将按照指示将其缓冲区caching刷新到磁盘。
还有其他的RAID驱动程序的情况下，HBA驱动器有错误，导致同样的问题。
我在这里谈论这个，SQL Server团队的Bob Ward在这里谈论它。
根据我的经验，任何性能上的收益都会被有一天会咬你的问题所抵消。 我想说，如果数据增长速度相对较慢，数据库代码更改较less，则可以有效地实现这一点并获得一些好处。 但是，如果你的数据库被大量使用，有时SQL页面出来，我会说不要打开它。 正如Ask the Performance Team的文章所述：
“一旦根据性能监视器分析的结果configuration了服务器，那么这个决定就完全取决于你了。”
我还没有find任何理由来打开它，在我的任何系统上