在一个典型的 SAP S/4HANA 生产系统里，我们很容易遇到这样的数据规模。销售订单抬头表已经有几千万条记录，订单项目、凭证流、定价元素或者库存相关明细表则可能达到数亿条。业务页面真正需要的，也许只是某一个销售组织、某一个工厂、最近一个月的数据。如果过滤条件能够在 SQL 执行的早期直接作用到这些大表上，SAP HANA 的列存储引擎往往可以很快完成扫描、过滤和 Join。可一旦过滤条件停留在 CDS View Stack 的上层，没有继续下推到真正承载海量数据的底层表，数据库面对的就不再是几百、几千条候选记录，而可能是几百万甚至几千万条中间结果。这类性能问题有一个很容易误导我们的地方。从 ABAP CDS 代码表面看，WHERE明明已经写了。业务查询甚至也传入了条件。可运行时间依然是几秒、十几秒，甚至更长。问题往往并不是有没有过滤，而是过滤有没有真正走到应该过滤的地方。SAP HANA 很擅长在 Column Store 中寻找满足条件的数据，但大规模 Join 仍然需要付出代价。特别是从数千万或者数亿行的表中取出数百万行参与 Join 时，如果缺乏足够有选择性的过滤条件，中间数据量会迅速膨胀。SAP 官方的 HANA 性能资料也一直强调尽可能早地减少数据量。对于 Join 场景，SAP HANA 的 Filter Mapping 机制甚至专门用于将一个 Join Partner 上的过滤条件映射到另一个 Join Partner，以便更早缩小两侧数据集。如果某条查询每天只在后台执行一两次，而且只有少量用户使用，数秒的响应时间未必会形成严重问题。但如果同一条 CDS 查询支撑的是 SAP Fi