在这篇关于CDS视图性能方面的博文中，我想讨论如何在构建和访问CDS视图时确保良好的性能。基本上，这都是一些简单的SQL性能规则，在使用CDS视图和HANA时，这些规则有时会被遗忘，但仍然有效，或者只需要一个温和的新解释。

以下是博客系列的议程：

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

正如我们在之前的博客文章中看到的，当从ABAP或HANA studio访问CDS视图时，我们构建的反映数据模型的CDS视图和表的层次结构变成了纯SQL。我们的意图（即我们要读取的数据）是在一个SQL字符串中声明的，SQL优化器将处理该字符串以创建执行计划。因此，在开始任何有关CDS视图的工作之前，应该先复习一下SQL的知识。这对于我们这些长期从事ABAP开发的人来说尤其重要，他们以前常常不敢实现连接3个以上表的abapopensql语句。如果您现在开始创建包含几十个底层表的CDS视图，您应该意识到这可能会创建的复杂性，你应该有相当多的SQL专业知识来理解处理复杂的SQL语句对数据库意味着什么。

一个好的起点是记住经典的SQL性能规则，物联网流量卡，如"避免循环中的SQL语句"或"在WHERE子句中完全指定所有已知的筛选字段"。其中一些规则反映在SAP数据库编程的5条黄金规则中（请参阅HANA上的ABAP第2部分-从分析到优化）。从这些规则中，我推断出了我认为与实现CDS视图和访问这些CDS视图的SQL语句最相关的内容。

数据库处理请求所需的表和视图越少，语句准备和计划创建的速度就越快，而且语句的执行也往往越快。CDS视图的维护将更加容易，正如我们在上一篇博文中所看到的，对于简单的CDS视图，创建的计划也将更加稳定。在较小的范围内，HANA需要从其列存储中访问的表中检索的列数也会影响运行时。因此，

在CDS视图中，只公开必需的字段，以减少访问的表、使用的联接和操作的数量使用关联而不是左外部联接，这样，只有当路径表示法显式请求关联中的字段时，才会执行其他联接如果可能，将外部联接定义为左外部多对一联接和具有"对一"基数（[n..1]）的关联。在这种情况下，如果没有从联接表请求任何字段，则数据库可以避免在运行时执行联接。请注意，错误地表示"对一"基数可能会导致函数错误，如果为真，则基数将为"对多"。在访问CDS视图的SQL语句中，只请求应用程序所需的字段。SELECT*语句需要访问许多列，这为HANA列存储创建了一些开销。您应该更喜欢使用定义良好的字段列表。但是请注意，对同一个表/视图进行多次访问并使用不同的字段列表是不值得的。只有一个数据库访问需要处理应用程序所需的所有字段，这样更有效。使用冗长的GROUPBY子句还需要访问许多列。通常，尽量避免CDS视图中的groupby子句在CDS视图层次结构中重复使用。数据建模技巧将在下一篇博文中介绍。请注意，任何CDS视图都应该非常适合它必须满足的业务需求，并且不应该包含多余的表。不能夸大CDS视图的重用，因为对于一个应用程序来说，只有一个或少数几个一刀切的视图可以做几乎所有的事情（即回答所有可能的查询）。

在下面的ABAP代码片段中，CDS视图上有一个ABAP Open SQL连接I\u BUSINESSUSER和I\u PERSONWORKAGREEMENT，分别有9个和5个基础表。这个连接导致了一个非常复杂的SQL语句，大数据服务，实际上，代码的作者只是想对某个用户ID做一个存在性检查，只需连接两个表就可以简单得多。作者应该与CD视图的所有者交谈，询问他们是否可以提供更适合、更苗条的CD视图。

HANA在其列存储中搜索条目的速度非常快。另一方面，加入非常大的表也会占用HANA的时间。如果要将标题表中的数百万个条目与关联行项目表中的10或100个数百万个条目连接起来，并且没有应用任何有效的筛选器，那么响应时间将在多秒范围内也就不奇怪了。这样的响应时间对于很少执行的语句来说是可以的，可能一天一到两次由一小群用户执行。如果您希望一条语句被许多用户频繁地执行，那么情况就完全不同了。然后，为了保持低系统负载和高用户满意度，您需要在（亚）秒范围内实现响应时间。如果您的语句正在从包含大量（数百万）条目的表中读取数据，则必须使用有效的筛选器来减少要处理的数据量。