Telerik RadGrid处理海量数据时选哪种绑定方式性能更优？

• 采用全量客户端绑定替代现有服务端绑定完全不可行，属于典型的性能反向优化，会让现有卡顿问题进一步恶化。
• 百万级数据场景下，RadGrid性能最优的方案是数据库侧执行过滤/排序+服务端自定义分页的按需绑定模式，没有其他替代方案能达到同等性能表现。

100万条结构化业务数据做全量客户端绑定，会带来三个无法解决的性能瓶颈：

• 数据序列化+网络传输成本极高：单条数据按10个业务字段计算，全量序列化后的JSON体积可达300-500MB，仅传输环节就要消耗数十秒
• 客户端内存占用溢出：浏览器接收全量数据后，JS解析、维护数据集合、渲染DOM会占用1.5G以上内存，极易触发浏览器无响应甚至崩溃
• 前端计算效率极低：客户端筛选、排序依赖JS单线程遍历全量数据，单次操作耗时会超过当前服务端处理的5分钟，完全不具备可用性。

单次筛选等待5分钟的问题，本质是服务端绑定的实现方式错误：常规错误实现是一次性将100万条数据全量查询到Web服务内存，交给RadGrid在进程内存中执行筛选、排序计算，同时控件会将全量数据写入ViewState，导致回发请求体积爆炸、服务端CPU/内存占用被拉满，和服务端绑定本身的技术路线没有关系。

按以下规则调整后，筛选、排序操作的端到端响应速度可以稳定在1秒以内：

• 开启RadGrid自定义分页能力，配置AllowCustomPaging="true"、AllowPaging="true"，永久禁用全量数据加载逻辑，任何场景下都不要在Web服务内存中留存全量100万条数据集
• 依托OnNeedDataSource事件实现按需加载：每次事件触发时，直接从RadGrid上下文获取当前筛选条件、排序规则、页索引、单页大小参数，将筛选、排序、分页逻辑全量下推到数据库执行，通过分页查询语法（如SQL的OFFSET/FETCH、ORM的Skip()/Take()）仅查询当前页需要的50-200条数据，同时查询符合筛选条件的总记录数赋值给控件的VirtualItemCount属性
• 关闭冗余视图状态，配置EnableViewState="false"，按需加载模式下不需要留存全量控件状态，可将每次回发的请求体积缩小90%以上
• 给所有参与筛选、排序的数据库字段建立对应索引，避免数据库执行条件查询时出现全表扫描，百万级数据表带索引的条件查询响应时间通常在几十毫秒级别
• 若要进一步优化交互体验，可开启AllowVirtualScrolling="true"，用虚拟滚动替代传统分页按钮，用户感知和全量客户端绑定无差异，但性能差距可达两个数量级。

注意：不要尝试将全量数据加载到服务端缓存、客户端本地缓存做内存筛选，百万级数据的全量内存计算效率，远低于数据库带索引的查询效率。

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