在 SQL Server 中识别/识别“坏”参数嗅探的方法

Question

有很多关于可用于减轻不良参数嗅探的某些方法的极好信息，但关于如何识别不良参数嗅探问题的信息并不多。

假设您没有使用 SQL Server 2016，因此无法利用查询存储，并且您没有用户抱怨有问题的存储过程间歇性地执行不佳，那么可以使用哪些方法来主动识别错误的参数嗅探问题？

利用扩展事件、RML 实用程序和简单地查询/轮询 DMV 似乎都是可行的方法，有没有人有使用这些方法中的任何一个的方法或知道任何描述如何执行此操作的好资源？

Answer 1

识别参数嗅探是一项艰巨的工作！使用监控工具或查询可能并不明显，因为它通常需要对其他对查询计划执行进行。

这是 DMV 和 sp_BlitzCache 之类的计划缓存分析工具可以提供帮助的地方。你可以在这里下载。完全披露：我为 Brent Ozar 工作，并为该项目做出贡献。

它仅使用您的指南提供的 DMV 来执行计划缓存等分析。它也是免费的。如果您无法安装存储过程，则尝试识别参数嗅探的相关代码位在这里：

 parameter_sniffing = CASE WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND min_worker_time < ((1.0 - (@parameter_sniffing_warning_pct / 100.0)) * AverageCPU) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND max_worker_time > ((1.0 + (@parameter_sniffing_warning_pct / 100.0)) * AverageCPU) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND MinReturnedRows < ((1.0 - (@parameter_sniffing_warning_pct / 100.0)) * AverageReturnedRows) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND MaxReturnedRows > ((1.0 + (@parameter_sniffing_warning_pct / 100.0)) * AverageReturnedRows) THEN 1 END

如果您使用存储过程，这些变量是可配置的。如果您想自己滚动，则如何分配值取决于您。我们所看到的是某些计划属性的平均值是否被严重超过，或者，呃...低于这些属性的最小值/最大值。

这些通常是参数嗅探的良好指标。考虑执行 5 次键查找的“小”值计划（并且在多次执行中适用于大多数值）。如果接下来出现一个“大”值并使用缓存计划，迫使键查找执行数十万次，它将使用更多 cpu/执行更多读取/运行时间超过平均水平。

希望这可以帮助！