在这篇博客文章中，我描述了HANA优化器如何从SQL语句创建执行计划，该计划如何进入计划缓存，以及在分析HANA studio的SQL语句时应该考虑什么。因为我的主要兴趣是CDS视图的性能，所以我将集中在资源和运行时方面第2部分-HANA SQL优化器和计划缓存-本博客第3部分-CDS视图良好性能规则第4部分-数据建模第十部分-也许更多…你的想法或问题
在上一篇博文中，我们已经看到在ABAP代码中访问CDS视图时创建的SQL语句可能变得相当复杂。除了视图本身的"静态"复杂性之外，当遵循关联时，或者当视图分配了DCL（数据控制语言对象，即权限检查）时，可能会连接其他表或视图。
为了使HANA能够响应数据库请求，它需要SQL语句的执行计划，这是一种描述如何检索数据和准备输出的方法。这个方法不在SQL语句中，因为SQL是一种声明性语言：它只描述要处理的"什么"，而不是"如何"。没有规范，也没有数据库是否应该应用嵌套循环联接、哈希联接或半联接来获得结果。实际上，"如何"留给了SQL处理器，它根据关系代数的规则，借助数据库表统计，提出了一个执行计划来处理SQL语句。
在创建计划的过程中，SQL处理器使用SQL字符串中给出的信息创建多个计划，对这些计划进行评估，以找到最佳（或至少是好的）执行计划。理想情况下，连接重新排序可以在SQL语句的所有连接之间进行，并且其他运算符（如筛选器或聚合）也可以在计划变体中"移动"。
下图显示了HANA PlanViz的两个屏幕截图。两个计划的executed语句相同，但系统和数据星座不同。我们发现，最终的计划是完全不同的；例如，包含最慢运算符（红色圆圈）的关键路径改变了其位置。这就是为什么复杂的语句必须用类似于产品的数据来测试，以获得相关的结果。
正如我们所看到的，要确定复杂SQL语句的执行计划，需要评估数千种不同的计划变体。下面的屏幕截图显示了具有高计划准备时间（列TOTAL\u preparation\u time）的SQL语句的SQL计划缓存。数值以µs为单位，因此这些语句的计划准备时间很长。
此准备时间取决于SQL语句的复杂程度，加起来等于一条语句的总执行时间，因此不应忽略！下面我们将看到，HANA计划缓存缓解了这个问题。
为了避免CDS视图性能不稳定或缓慢的意外情况，您应该
使CDS视图尽可能简单，仅根据实现业务案例目标的需要尽可能复杂。如上所述，如果复杂性太高，返利系统，SQL优化器可能无法确定SQL语句的"最佳"计划。此外，在重新创建计划之后，复杂SQL语句的执行计划和执行时间可能会发生变化。在有效地使用重要的SQL语句之前，请使用类似于产品的数据（即数据量和数据分布都应该是真实的）对它们进行彻底的测试。使用ST05（性能跟踪）和hanaplanviz跟踪和分析单个关键SQL语句。在HANA升级之后，或者当基础表中的数据量发生巨大变化时，控制业务关键型SQL语句的执行。使用HANA计划缓存或SQLM（ABAP服务器上的SQL监视工具）监视总体SQL性能。按照注释1794297中的说明检测可能受益于二级索引的表
对于长时间运行的分析查询，可以在每次执行中花费一些时间和内存来创建计划和编译语句。这对于在事务性进程中执行的SQL语句是不可能的，因为在事务性进程中，响应时间必须在毫秒范围内。在这里，准备时间可能会超过执行时间。这就是saphana将优化的SQL语句存储在计划缓存中的原因。它将查询的SQL字符串（加上一些附加信息）与已编译的查询执行计划相关联。完全相同的语句不需要解析，服务器云服务器，计划也不需要每次都重新编译，但只能在计划失效/收回之后（见博客末尾）。
但是什么是完全相同的SQL语句？如果您想使用hanaplanviz工具调查一些性能问题，那么您当然有兴趣获得与您的性能问题相关的计划。如下图所示，即使在两条完全相同的SQL语句中的一条中添加一个小注释，也会导致不同的执行计划，这些执行计划可能具有不同的运行时：
这种效果对于某些框架创建的SQL语句并不重要，云 服务器，因为它们总是具有相同的格式。这与手工编写的abapsql更相关，因为WHERE子句中字段的不同顺序也会导致不同的计划。对于ABAP中的SQL语句，建议按照访问字典对象（表或SQL视图）中字段的顺序指定WHERE子句中的字段。
语句标识的另一个重要因素是SQL语句的参数（CDS view parameters and parameters in WHERE子句，GROUP BY，订货人……）。如果SQL语句的每个参数集都会导致一个自己的计划缓存项，云是什么，那么缓存中很快就会充满大量结构相同的语句。为了避免这种情况，来自ABAP的语句被发送到数据库中，其中包含大多数参数值的绑定变量（显示为"？'在ST05 SQL Trace的SQL语句中）。只有当ABAP识别出某个参数值是常量时，它才会作为文本值传递给数据库。
