网络 I/O 是否包含在 SQL Profiler 中看到的“RPC 完成”的计时中？
Tim*_*ker 3 performance sql-server profiler
在 SQL Profiler 中查看结果时，RPC Complete 是否包括将结果发送到客户端的时间？或者只是服务器花在收集记录上的时间？
我问的原因是我正在开发一个程序来移动大量数据。数据库在 Azure 中托管在云中，代码（当前）在本地运行。我可以在 SQL Profiler 中看到 RPC 调用时间，并且选择行的查询并不便宜（由索引列过滤的海量表，然后按表的主键排序以获得分页结果），并且它不是一个微不足道的数量数据（每页 10 万条记录，在某些情况下，我每次运行最多可移动 6000 万条记录）。
我很好奇，一旦代码在 Azure 中运行，我是否应该期望它运行得更快。如果 RPC 完成时间包括将数据发送到客户端所花费的时间，那么这应该会减少一些（我希望会显着）。如果 RPC 完成时间只是服务器选择数据的时间，那么当它在 Azure 中运行时，我不会看到太多的增加。
网络I / O被包含在rpc_completed持续时间*，所以我希望你会看到你所描述的工作量提高。
我在本地 SQL Server 2016 实例上启用了 TCP/IP，然后通过使用 ORM 的 .NET 应用程序运行了一系列查询。以下是该测试运行中完全相同查询的扩展事件目标sp_statement_completed和rpc_completed扩展事件目标的比较：
每组两行是同一查询的两个事件。
请注意，rpc_completed它明显高于sp_statement_completed每次，因为后者不包括网络时间（它只是批处理中的语句在服务器上完成所花费的时间）。
为了笑，我然后关闭了 TCP/IP，以便查询将通过命名管道提供程序：
请注意，rpc_completed它仍然更高，但差异要小得多，因为没有 TCP 开销 - “往返”都在进行中。
*我的测试是使用扩展事件完成的，但我怀疑 Profiler 也是如此
需要明确的是，sp_statement_completed在“流媒体计划”的情况下也可以包括网络时间（感谢David Browne指出这一点）。
有时，尤其是具有大量结果的简单查询，在语句完成后不会对结果进行假脱机发送。而是在计划运行时发送结果。这有时被称为“流媒体计划”，这就是您通过简单的嵌套循环连接或从大表中选择 * 获得的结果。