在一个典型的 SAP S/4HANA 查询里，业务页面最终可能只需要订单号、客户、日期、净额和币种几个字段，但底层 CDS 数据模型却可能一路经过十几个 CDS View Entity，连接客户主数据、地址、文本、组织机构、状态、合作伙伴、产品描述等大量对象。SQL 最终当然还能执行出来，可一旦数据量扩大，响应时间、CPU 消耗和临时内存占用就可能迅速上升。
这类问题很容易被误判成 SAP HANA 数据量太大，或者某张业务表缺少索引。实际排查 CDS 性能问题时，经常更应该问一个更直接的问题。
SAP HANA 为了得到最终这几列数据，到底被迫读取了多少列、处理了多少行、中间产生了多少临时数据。
这也是设计高性能 ABAP CDS 数据模型时非常重要的一条原则，尽可能缩小 Result Set，并尽可能减少整个执行过程中流动的数据量。
SAP 官方 ABAP 性能资料同样强调，数据库访问应尽量减少返回行数，并只读取程序真正需要的列。对于列存储数据库来说，明确指定字段通常比无差别读取全部字段更合理。
这条原则看起来简单，但真正放到多层 CDS View Entity、Association、Aggregation 和复杂 Join 中，它影响的远远不只是网络上传回 ABAP Application Server 的字节数，而是会一路影响 SAP HANA 的 Column Scan、Join、Aggregation、Calculation、Intermediate Result，乃至最终生成的 Execution Plan。
少读取一个字段，不只是少传输几个字节
SAP HANA 是典型的列式数据库。对于分析型查询而言，这
