我们处理来自上游系统的 CSV 文件，并将它们加载到 SQL Server 数据库中的主表中。我们目前正在使用一个新的上游系统，突然我们的 UPDATE 语句花了很长时间。这可能是由于传入的数据在我们的系统中有以前的相关数据，并导致了巨大的更新。我们能够找到通过 更新的表sp_whoisactive。
我的查询是：
发布更新，有没有办法从错误日志或默认跟踪或通过 DMV 等某个地方计算表更新的行数？
在更新过程中，如果我们发现将来会发生这种巨大的更新，我们是否可以设置一些跟踪来识别将要更新的行数或找出具有当前参数（参数的当前值）的更新语句？在sp_whoisactive我们得到带有变量的更新语句。但我们不知道当前的参数。
我们是否应该主动设置扩展事件或其他东西来捕捉未来这些巨大的更新？
让我们先从你的第三个问题开始。是的。如果您真的想跟踪更改的特定值，最好的方法是通过扩展事件，您必须设置它并让它提前运行。正如您将在本文的其余部分中看到的那样，可能没有简单的方法来检索您正在寻找的特定信息，具体取决于。像 sql_statement_completed 这样的东西会给你一个给定事件的精确行数。您可以将其过滤到特定表。
第二个问题，在更新期间，您无法真正看到在事务中准确更新了多少行。但是，您可以猜测可能会更新多少行。执行计划将具有预期会发生的行估计。因此，您可以从 sys.dm_exec_query_plan 中查询。将其与 sys.dm_exec_sql_batch 结合以查找查询。我确信 sp_whoisactive 也可以提供此信息（它只是查询 DMV）。如果您提前正确设置了服务器，您还可以观看实时查询统计信息。这将为您提供估计的行数，但随后会显示实际发生的行数。
现在是棘手的问题。事后你能得到行数吗？有点儿。如果查询刚刚执行并且没有再次执行，则 sys.dm_exec_sql_batch 确实有一个 last_rows 列来提供该信息。但是，如果运行了多个查询，则该信息会丢失，因为它只是最近一次执行的查询。如果您使用的是 Azure SQL 数据库或 SQL Server 2019，您还可以查看 sys.dm_exec_query_plan_stats以查看最后的执行计划加运行时指标。这也将有行数虽然，如果这就是您要寻找的全部，并且这是最近的执行，那么批处理 DMV 会更容易。我不知道该列是否包含在 sp_whoisactive 中，但您可以自己查询 DMV。
但是，如果查询运行了不止一次，那么您就不走运了。如前所述，您可以查看执行计划以查看行估计值。如果查询等待超过 30 秒，它将显示在 system_health 扩展事件会话中，但不包括行数。真的，除非它是最后一次运行确切的查询，否则在事后无法获得行计数值。