随着SAP HANA平台在每个新版本中的发展，SQL优化团队不断增强额外的优化，并支持为每个版本添加新功能。通过新的改进，SQL查询处理器生成的计划与以前的版本有些不同，可能会出现一些性能退化。引入SQL计划稳定性是为了避免这种可能的性能退化，并将执行时间控制在预期的范围内。
为了理解这是如何实现的，让我们深入了解SQL查询处理器在幕后是如何工作的。当从客户机接收到一条新的SQL语句时，啥叫大数据，SQL优化器将对其进行评估，并执行几个步骤来编译、选择和缓存最佳的物理执行计划。下图显示了没有SQL计划稳定性的简化步骤。
有了SQL计划稳定性，大数据数据库，物理执行计划相关的信息被收集并存储为抽象SQL计划（ASP）到持久存储以备将来参考。此信息可用于跳过现有的重写步骤，但仍然能够基于存储在ASP中的逻辑计划和物理属性重新创建相同的执行计划。
现在让我们看看何时再次收到相同的SQL语句。如果计划缓存已经被缓存以加快执行，则首先检查该语句。有时现有计划会失效，需要重新编译。此时，当SQL计划稳定性激活时，它将检查SQL语句的抽象SQL计划是否已经存在。与SQL计划缓存不同，除非手动删除，否则抽象SQL计划不会被逐出并保存在存储中。如果ASP已经存在，企业信息化应用系统，则将具有物理属性的逻辑计划加载回SQL查询优化器，企业信息软件，进行验证并传递到执行计划生成步骤以进行最终编译。
我们测试了从HANA 1.0 SPS12升级到HANA 2.0 SPS03的过程，其中202条语句被捕获为ASP，其中包含每条语句的执行时间在以下测试结果中
如果条件相同，则执行时间相同，并按对角线排列。下面一行显示改进，上面一行显示回归。首先，左侧显示没有平面稳定性的结果。为了提高回归语句的执行时间，采用ASP来执行已有的执行计划。对于改进的语句，不应用ASP来保持执行时间的改进。右侧显示ASP激活后的结果，用回归改进语句。
使用新的SQL计划稳定性，世界人工智能，获得了两个关键好处。首先，存储的ASP将根据现有的逻辑计划和尽可能保存的物理属性生成相同的执行计划。因此，它将避免任何性能退化，并实现计划的稳定性。第二，跳过逻辑计划枚举步骤，减少总编译时间，这可以减少非常复杂查询的准备时间。
SQL计划稳定性是一个两步过程。首先，"捕获"存储ASP。其次，"Apply"激活ASP创建执行计划。有关限制的最新信息，请参见附注#2639193–SAP HANA SQL计划稳定性。
