使用ADO.NET DataReader与WebSocket实现懒加载时ExecuteReader性能差异问题

核心原因 #

• 数据库执行逻辑差异
  SELECT TOP 1查询仅需扫描到第一条符合条件的记录就会终止执行，资源消耗极低。而全量SELECT需要完成全表扫描、结果集整理（含排序、临时表生成等操作），数据库需要将全量结果的元信息、首批返回数据准备完成后才会响应客户端，这部分开销全部计入ExecuteReader的耗时。
• DataReader默认机制和认知偏差
  你认为Read()方法才会拉取单条数据的认知有误。默认配置下DataReader启用批量拉取逻辑，ExecuteReader执行时数据库会先将数千条结果打包写入客户端网络缓冲区，Read()仅从本地缓冲区取数，不需要实时和数据库交互。全量查询的结果集越大，数据库侧生成首批可返回数据的时间越长，部分场景下数据库甚至会先将全量结果写入磁盘临时文件再开始返回，进一步拉长耗时。
• 资源竞争开销
  数百万条记录的全表查询会占用大量数据库CPU、内存、磁盘IO资源，还可能触发锁等待，这些额外开销都会被计入ExecuteReader执行时间，TOP 1查询几乎不会产生这类资源占用。

懒加载场景优化建议 #

• 避免直接执行全量SELECT，改用分页查询：借助自增主键分段拉取，例如SELECT * FROM 表名 WHERE id > 上一批最大id LIMIT 1000，单次仅拉取固定数量的记录，平摊查询压力。
• 开启流式读取：如果使用SQL Server，调用ExecuteReader时传入CommandBehavior.SequentialAccess参数，让数据库逐批返回结果，不需要等待全量结果集准备完成。
• 调整DataReader拉取批次大小，和WebSocket推送速率匹配，避免本地缓冲区堆积过多未推送数据。

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