在这一系列的博客文章中，我想讨论abapcds视图的一些性能方面。作为一名性能专家，我每天都在研究CDS view性能主题，我希望能够从我的经验中提供一些见解。

我大致计划涵盖以下几点，但如果这与CDS view性能有关，请您提出更多要求。如果有必要，我会咨询真正的专家…

第1部分-CDS查看复杂性-这个博客第2部分–HANA SQL优化器和计划缓存第3部分-CDS视图良好性能规则第4部分-数据建模第十部分-也许更多…你的想法或问题

作为对草率读者的一种服务，我把这篇博客文章的建议放在开头，这样你就不必向下滚动所有的细节来找到它们：

通过使用ADT中的依赖分析程序来关注CD视图的复杂性从创建简单的CDS视图开始，谨慎地继续创建更复杂的视图只公开必需的字段，以减少访问的表、使用的联接和操作的数量通过使用关联而不是左外连接来降低复杂性如果可能，允许使用选项LEFT OUTER join MANY TO ONE进行连接修剪维护CD视图的性能注释不要创建包含超过100个基础表的CDS视图。特别是，遵循CDS视图中关于服务质量A、B或C的更严格的建议数据模型的质量和底层数据源中的数据量在运行时比普通CDS视图的复杂性更具决定性

SAP虚拟数据模型（VDM）的一个关键原则是"一次建模-到处使用"。这意味着VDM可以用于事务应用程序、分析查询、api、扩展视图等。它还提示重用VDM的构建块、CDS实体，并在它们的帮助下将复杂的应用程序逻辑下推到HANA数据库中。

由于构建和堆叠CDS视图非常容易，因此存在使单个CDS视图"过于复杂"的危险。在实现过程中，您应始终尽量接近目标业务目的，并避免与应用程序无关的额外选择和操作。

阅读第4部分-数据建模中的更多信息。

跟踪CDS视图的复杂性，在ABAP Development Tools（ADT）中显示复杂性度量，选择鼠标右键菜单"Open With"–>"Dependency Analyzer"。

在Dependency Analyzer中，视图层次结构和复杂性通过3个工具可视化：

SQL Dependency TreeSQL依赖关系图复杂性度量

复杂性度量的一个简单KPI是CDS视图用作数据源的数据库表的数量。显示的数字包括在CDS视图或其基础视图层次结构的设计时定义中"使用"的所有表。对于关联可以访问的表，只有那些表包含在度量中，在设计时关联已经被遵循。运行时在SQL访问中使用显式路径表示法可以遵循的关联不计算在内。

当然，还有许多因素会导致CDS视图的复杂性：连接和并集操作、大小写表达式、函数和计算、聚合等。在下面的一篇博文中，我们将看到，例如，计算会对CDS视图的性能产生重大影响。但现在，让我们仅限于简单的"表数"指标。

对于CDS视图开发，SAP定义了三个性能注释（请参阅SAP s/4HANA合作伙伴解决方案要求–注意：链接仅适用于客户和s-user合作伙伴中的第7章性能要求）。在SAP，必须为每个非私有CD视图维护这些注释—我们强烈建议我们的客户和合作伙伴也这样做。通过这些注释，视图的作者表示CDS视图的使用者可以期望的服务质量、大小类别和数据类。在服务质量方面，要求在频繁执行的事务流程中，只使用服务质量高的A或B的CDS视图。另一方面，用这些服务质量注释的CDS视图必须满足几个要求，例如在简单密钥访问中的响应时间。另一个方向是，淘客app源码，服务质量为A的视图不应该有超过3个底层表（对于B，它有5个表），其中的数字是指ADT中的复杂性度量。为回答复杂的分析性查询而构建的CDS视图将具有服务质量D，并且不应具有超过100个基础表。

当查看许多不同CDS视图的SQL语句运行时统计信息时，发现观察到的运行时仅与基础表的数量适度相关。当然，随着视图中连接和其他操作的数量增加，内置建模缺陷的风险也随之增加。但是，使用几十个表可以获得良好的性能，而对于只有3个底层表的视图，大数据技术及数据分析培训，也可能获得较差的响应时间。比数据源的普通数量更重要的是这些数据源中的数据量和数据模型的质量。

尽管如此，所描述的为服务质量A和B设置的复杂度KPI，因为对于数据源数量有限的CD视图，什么叫物联网，运行时将更好地预测，创建计划的时间将更快，创建的计划将更稳定，云服务器网站，更易于分析。对于这些主要使用CDS键访问的视图，可以很容易地设置和监控自动运行时测量。

当执行Fiori应用程序时，用户参数将通过OData查询选项传递给ABAP后端的一些处理程序逻辑。SADL框架要么在CDS视图上构建一个SQL语句，直接传递到数据库，要么调用一些ABAP处理逻辑，在CDS视图上执行select或join。

在这两种情况下，生成的SQL语句将包含对CDS视图的访问，CDS视图本身就是一个SQL表达式，加上以下一个或几个成分：