我们处理来自上游系统的CSV文件，并将其加载到我们SQL Server数据库的主表中。我们现在正在上一个新的上游系统，突然我们的UPDATE语句花了很长时间。可能是由于传入的数据在我们的系统中有以前的相关数据，导致更新量很大。我们能够找到被更新的表，并通过 sp_whoisactive.
我的疑问是。
发布更新有什么方法可以从错误日志或默认跟踪或通过DMV等地方计算出表的更新行数？
在更新过程中如果我们发现将来会发生这种巨大的更新，我们是否可以设置一些跟踪来识别将被更新的行数，或者找出当前参数的更新语句（当前参数值）？在这里，我想说的是，如果我们在未来发现有这种巨大的更新发生，我们是否可以设置一些跟踪来识别行数，或者用当前的参数（当前的参数值）来计算更新语句？sp_whoisactive 我们得到带有变量的更新语句。但我们不知道当前的参数。
主动地，我们是否应该设置扩展事件或者其他的东西来捕捉未来这类巨大的更新？
先说说你的第三个问题吧。是这样的。如果你真的想跟踪特定的变化值，最好的方法是通过Extended Events，你必须提前设置并让它运行。正如你将在这篇文章的其余部分看到的那样，可能没有简单的方法来检索你正在寻找的特定信息，这取决于。像sql_statement_completed这样的东西会给你一个给定事件的精确行数。你可以过滤到一个特定的表。
第二个问题，在更新过程中，你无法真正看到一个事务中有多少行被准确更新。但是，你可以猜测有多少行可能被更新。执行计划会有它预计会发生的行数估计。所以，你可以从sys.dm_exec_query_plan中查询这个。结合sys.dm_exec_sql_batch来查找查询。我相信sp_whoisactive也能提供这些信息（只是查询DMVs）。你也可以看 实时查询统计 如果你已经提前正确设置了你的服务器。这将给你估计的行数，但随后它会显示你的实际情况，因为他们发生。
现在是个棘手的问题。你能在事后得到行数吗？可以。如果查询刚刚执行，并且没有再次执行，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扩展事件会话中显示出来，但这不包括行数。真的，除非是最后一次运行准确的查询，否则事后是没有办法得到行数值的。