在一个成熟的 SAP S/4HANA 项目里，真正让人头疼的 CDS 性能问题，通常不是某条 SQL 突然慢了几百毫秒，而是一个原本只打算用于单对象读取的 CDS View Entity，被越来越多的上层应用拿去做列表、批处理、统计、OData 查询，甚至直接成为新的 CDS 数据模型底座。
代码本身没有发生明显变化，业务数据却从几十万行增长到几千万行。某个最初只关联三张表的 View，几年以后已经叠到了十几层 CDS。开发阶段在测试系统里执行依旧很快，一进生产系统，高峰期的 SAP HANA CPU、内存和临时结果集消耗便完全变成另一幅样子。
这类问题只靠 SQL Trace 很难在设计阶段预防。
SAP 在 ABAP CDS 里设计Performance Annotations，正是为了给 CDS Entity 增加一层明确的性能语义。它们不是数据库 Hint，也不会直接告诉 SAP HANA Optimizer 应该选择 Hash Join 还是 Nested Loop，更不会因为写上一行 Annotation 就让 SQL 自动快十倍。
它们承担的是另一种职责。
一份 CDS 数据模型不仅要告诉消费者有哪些字段、有哪些 Association、有哪些业务语义，还应该告诉消费者，这个实体适合放在哪种负载场景里，它背后可能面对多大的数据空间，以及其中的数据属于什么生命周期。
SAP 目前推荐的三个核心注解就是
@ObjectModel.usageType.serviceQuality
@ObjectModel.usageType.sizeCategory
