SqlCommand.ExecuteReader()工作机制及大结果集下带宽飙升问题咨询

嘿，这个问题问到点子上了——很多人都会对ExecuteReader()的实际运行逻辑有误解，我来给你掰扯清楚：

首先纠正一个常见误区：ExecuteReader()并不是只在调用Read()时才开始从服务器拿数据。当你调用这个方法的瞬间，.NET的SqlClient就已经和SQL Server打通了数据传输通道，SQL Server这边会立刻开始把生成的结果集往客户端推送——只不过默认情况下，SqlClient用了「行集缓冲」的策略来控制内存占用，不会一次性把所有数据都塞进内存里。

具体的流程是这样的：

• 调用ExecuteReader()后，客户端给SQL Server发执行请求，数据库执行完查询就开始生成结果集。
• SQL Server会把结果集拆成一个个8KB左右的数据包，持续不断地往客户端发。
• 客户端的SqlClient内部会维护一个接收缓冲区（大小可以通过SqlCommand.PacketSize调整），当缓冲区被填满或者服务器发完一批数据时，客户端会暂时把这些数据存起来，等你调用Read()的时候再逐行返回给你。
• 你调用Read()的时候，其实只是从本地缓冲区里取一行数据，不是每次都去服务器拉——只有当本地缓冲区的数据被取完了，才会触发下一次从服务器拉取数据包的操作。

你看到的带宽飙升，本质就是SQL Server在主动把结果集数据包推送给客户端，这个过程从你调用ExecuteReader()就启动了，根本不需要等到你调用Read()。

那为什么内存能保持稳定呢？因为SqlClient并没有把那1000万行数据全部加载到内存里，而是用了「流式处理+本地缓冲」的策略：

• 服务器不停发数据包，客户端接收后存在本地缓冲区里。
• 你调用Read()取数据，缓冲区空了就再从服务器拉一批。
• 已经被读取过的缓冲数据会被及时释放掉，所以进程内存不会暴涨，只会维持在缓冲区的大小左右。

简单总结：带宽涨是因为服务器在主动推数据到客户端的缓冲区，内存稳是因为客户端没把所有数据都留在内存里，用多少取多少。

你可以做个小实验来验证这个逻辑：

• 在调用ExecuteReader()之后，完全不调用Read()，等个几秒再看带宽和内存。你会发现带宽依然会上升（服务器在往客户端缓冲区推数据），但内存只会涨到缓冲区的大小就停住了。
• 如果你在ExecuteReader()之后立刻调用reader.Close()，带宽会马上降下来——因为客户端通知服务器停止推送数据了。

要是你想更严格地控制数据拉取的时机，可以在调用ExecuteReader()的时候指定CommandBehavior参数：

• 比如CommandBehavior.SequentialAccess，它会强制客户端只能按顺序读取数据，并且不会在本地缓存过多数据，特别适合处理超大结果集。
• 不过哪怕用了这个参数，SQL Server还是会主动推送数据到客户端，只是客户端的缓冲策略会更严格而已。

内容的提问来源于stack exchange，提问作者benjinne