SQL Server 2016 中引入的新查询存储很棒。它很好地替代了我以前使用旧的 Profiler 工具所做的大部分工作。但是，我还没有找到一种方法来捕获与对它嗅出的高资源消耗查询的单个调用相关联的参数值。这可能吗？
我知道查询存储更多地处理聚合数据而不是单个调用，所以我怀疑我在这里可能不走运。当我发现一个缓慢的查询时，我发现将参数与其最慢的调用之一关联起来也很方便进行故障排除。我想知道如何使用最新最好的工具来做到这一点。（我不会错过使用 Profiler！）
在安全方面，查询存储比 Profiler 更容易锁定吗？我认为它需要从某个级别的单个调用中捕获数据才能计算聚合。只是不确定它是否存储了其中的任何一个。
performance sql-server sql-server-2016 query-store query-performance
我正在解决与 SQL Server（技术上是 Azure SQL 数据库）相关的问题，偶尔会选择错误的执行计划，大概是由于统计数据不准确。sp_updatestats每次都修复它，直到几个小时或几天后，一个糟糕的计划再次被缓存。
看着“糟糕”的计划，我注意到一些让我感到奇怪的事情：在当前大约有 170 万行的表上有一个聚集索引查找。此操作的“估计行数”约为 1200，这绝对符合我在这种情况下对该操作所期望的平均行数，但“实际行数”超过 6000 万！沿着这个叶节点的粗线，在所有 6000 万个节点上执行各种下游操作，例如连接和排序，导致过慢、溢出到 tempdb 和其他坏处。
我一定误解了聚集索引查找实际上是做什么的，因为我认为它不可能“输出”比基础表中更多的行。什么可能导致这种情况？更好的是，有关如何修复它的任何指示？
[包含诸如“sp_updatestats每次修复它但无法弄清楚如何永久修复它？阅读这篇文章”之类的奖励积分。这是我们最近在几个不同方面的普遍问题。]