ADO采用adUseClient客户端游标的Recordset的CacheSize属性是否有效？

如果创建了配置 CursorLocationType.adUseClient 的 ADO Connection 实例，并用该连接打开 Recordset，此时调整 Recordset.CacheSize 属性是否会产生实际作用？结合现有文档和第三方描述的矛盾，该场景下的真实运行机制究竟是怎样的？

现有参考的冲突点 #

• 官方对 CacheSize 的基础定义：该属性用于控制每次从数据提供程序检索到本地内存的记录数量。
• 官方对客户端游标的说明：通过 adUseClient 类型的 CursorLocationEnum 指定客户端游标时，非键集客户端游标会将整个结果集通过网络从服务端传输到客户端计算机。
• 第三方技术文章的矛盾描述：客户端游标场景下，CacheSize 会控制ADO从数据库抓取数据的节奏——比如分页展示10条记录时把缓存设为10，ADO只会先抓取前10条，只有请求超出缓存范围的记录时才会访问数据库。这一描述和“全量传输结果集到本地”的官方说明存在明显冲突。

实际运行机制拆解 #

核心结论 #

adUseClient 场景下的 CacheSize 确实会产生实际作用，但它的作用边界完全不涉及和服务端的网络交互。网上的矛盾描述本质是混淆了客户端游标和服务端游标两层完全独立的逻辑。

1. 网络传输行为完全不受 CacheSize 影响
   只要连接配置了 adUseClient，无论你把 CacheSize 设为1还是1000，在执行 Recordset.Open() 时，服务端都会把匹配查询条件的全量结果集一次性通过网络传到客户端的ADO客户端游标引擎内存中，不存在“按缓存大小分批从数据库拉取”的行为。这是客户端游标的核心设计目标——把游标维护、遍历排序的开销从服务端转移到客户端，减少服务端的资源占用。
2. 本地内存调度行为受 CacheSize 直接控制
   全量结果集传到客户端后，ADO不会一次性把所有记录的字段值、行索引全部加载到可直接读写的状态，而是按照 CacheSize 的配置，以固定大小的块为单位把记录加载到可访问的内存缓存页中：
   • 当你遍历记录、读取某一行数据时，如果目标行落在当前缓存页的范围内，直接从内存读取，不会触发额外的内存操作；
   • 如果目标行超出当前缓存的范围，客户端游标引擎会在本地内存中把对应范围的记录块换入到可访问缓存，这个过程完全发生在客户端进程内部，不涉及任何和服务端的网络交互。
3. 和服务端游标的机制差异对比
   • 配置 adUseServer 的服务端游标场景下，CacheSize 直接控制和服务端的交互频率：每次按照缓存大小批量从服务端拉取记录，减少跨网络的往返次数；
   • 配置 adUseClient 的客户端游标场景下，CacheSize 仅影响客户端本地的内存调度效率：设置过小会导致频繁的本地内存页换入换出，增加CPU内存拷贝的开销；设置过大虽然减少换页次数，但会占用更多连续内存空间，在结果集规模较大时可能造成客户端内存占用过高。

第三方描述的错误来源 #

你看到的博客中提到的“超出缓存才访问数据库”的行为，本质是服务端游标的缓存逻辑。作者撰写内容时没有实际抓包验证两种游标下的网络行为，想当然把两类游标的机制混在了一起，才造成了和官方文档的明显矛盾。

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