在 SAP Gateway 的实际运行环境里，有一类请求看起来非常普通，却很容易在数据规模增长之后变成性能问题。客户端需要周期性读取一个 EntitySet，希望知道从上一次读取之后，后台究竟新增了什么、修改了什么、删除了什么。如果每次都重新执行一次完整的GET_ENTITYSET，再把几千甚至几十万条记录重新传到客户端，功能当然可以完成，但数据库、ABAP 应用服务器、Gateway Runtime、网络以及客户端都在重复处理大量根本没有变化的数据。SAP Gateway 提供的Delta Query Support正是为这种场景准备的。SAP 官方对 Delta Query 的描述非常直接，它解决的问题可以理解为，从上一次读取以后，有哪些服务或者实体被创建、修改或者删除。整个机制采用 pull model，也就是变化仍然由客户端主动拉取，而不是服务器必须持续维护每一个客户端的同步 Session。SAP 还明确把 Catalog Service 作为 Delta Query 的典型应用场景。这类设计和传统全量查询最大的区别，并不是少传几个字段，而是客户端与服务端共同维护了一个时间边界。这个边界就是delta token。可以把一次完整同步理解成在数据时间线上插入一个书签。客户端第一次读取完整数据集时，SAP Gateway 除了返回业务数据，还返回一个delta token。客户端把这个 token 保存下来。过一段时间再次同步时，不再表达为把全部数据再给我一次，而是带着之前的 token 请求，从这个位置以后究竟发生了哪些变化。SAP 官方文档明确指出，服务端需