在 SAP Mobile Services 的Offline OData场景里，一个非常现实的问题始终绕不开。移动端已经把几十万条设备、工单、物料或者客户数据下载到了本地，第二天重新同步时，后台真正发生变化的数据也许只有几百条。如果客户端仍然重新执行一次完整的 Entity Set 查询，把几十万条记录重新传输一遍，网络、SAP Gateway、ABAP Application Server、数据库和移动设备都会承担大量没有业务价值的工作。SAP 官方对Offline OData的定义很直接，它位于后端OData Service与客户端离线存储之间，负责数据传输。当后端自身能够支持Delta Query时，SAP 当前的性能指南建议直接使用后端生成的Delta Token，这样可以减少数据库访问并改善同步性能。SAP 在另一份关于Change Tracking的文档里甚至给出了相当鲜明的性能对比，在初始数据量很大的情况下，启用变化跟踪之后，增量下载可能以秒计，而没有变化跟踪时，同类过程可能达到分钟甚至小时级。这里的具体数字来自 SAP Mobile Services 的实现环境，不能机械地套到所有 SAP Gateway 项目上，但背后的工程规律完全一致。Delta Query正是为解决这种问题设计的。SAP Gateway 对它的描述可以概括成一句非常容易理解的话，客户端希望获得的是自上一次查询以后，被创建、修改或者删除的数据，而不是整个集合当前的全部内容。它属于典型的 Pull Model，客户端根据需要周期
