从有限的信息中无法确定页面和行锁哈希表上的争用是实际问题还是其他问题的征兆，例如，进程遇到某种其他争执，这反过来又导致它们花费更长的时间 比正常情况更容易处理锁？

虽然20％听起来很高，但这是一个相对数字，因此某些情况会有所帮助，例如，在30分钟的时间段内，100个自旋锁请求中的20％可能不算什么大问题 在1分钟的时间内有1000万个自旋锁请求。

--------

假设您已经排除了有关CPU使用率高的"正常"解释（例如，逻辑IO计数高，需要编译的查询量大，配置已知/错误），那么我想得到一个更好的解释 有关该时段内所有自旋锁活动的图片...尽管您可以浏览 sp_sysmon 结果（以及潜在的自旋锁数据），但查询 master可能会容易一些。 .monSpinlockActivity （MDA）表。

注意：您还可以向技术支持索取名为 sp_spinmon 的自定义proc的副本以及使用说明，该自定义proc还可以提供有关自旋锁问题的详细信息。

由于 monSpinlockActivity 计数器代表自启动数据服务器以来的总计数，因此您需要对表进行定期采样，然后使用增量来找出给定时间段内的计数器值（ 例如，拍摄 monSpinlockActivity 的快照，等待1分钟，拍摄另一个 monSpinlockActivity 的快照，获取计数器的差，您将获得过去一分钟的旋转锁活动）。

注意：您需要确保启用自旋锁监视 = 1。

经常弹出的常见原因（CPU使用率很高）是过程高速缓存大小不足。 这将显示在 monSpinlockActivity 中，具有高（增量）旋转/抓取和等待/抓取的值。

--------

几个好的资源：

ASE WIKI页面re：自旋锁和（高 ）CPU使用率（包含用于示例 monSpinlockActivity 的示例代码）

Jeff Tallman的博客回复：调整大小 过程高速缓存（如果您发现真正的问题是与过程高速缓存相关的自旋锁争用，则可能与此有关）