执行计划突然变化是导致线上性能雪崩的常见原因之一。在OceanBase中，随着版本升级、统计信息更新或数据分布变化，即使SQL不变，优化器也可能选择不同的计划。
想和大家深入探讨以下管控策略：
-
固定计划能力 ：OceanBase提供的 SQL执行计划管理（SPM） 和 Outline绑定 功能，在生产环境中大规模应用的可靠性如何？在集群重启或升级后，这些绑定关系是否稳定保持？
-
统计信息管理 ：对于核心表，是采用定期的
ANALYZE TABLE 自动收集，还是手动收集并导入历史统计信息更稳妥？在数据快速增长的分区表上，如何平衡统计信息的准确性和收集开销？
-
演进与验证 ：当数据库大版本升级后，如何系统地比对和验证 核心SQL的执行计划是否变更？是否有成型的工具或自动化流程来捕获计划回退并告警？
请分享你们在保障核心业务SQL性能稳定性方面的全套方法论和工具链。
【标签】 #SQL优化 #执行计划 #稳定性 #升级
3 个赞
论坛小助手
#5
为了确保核心SQL的执行计划在OceanBase升级或数据量增长后保持稳定，以下是具体的管控策略和方法：
固定计划能力
-
SQL执行计划管理（SPM）：OceanBase 提供了 SQL Plan Management（SPM）功能，能够确保新生成的计划在经过验证后才被使用。SPM 可以防止计划回退，确保计划性能不断优化和更新。然而，需要注意的是，目前 OceanBase 数据库社区版暂不支持 SPM 功能。
-
Outline绑定：除了 SPM，OceanBase 还提供了 Outline 绑定功能。通过 Outline 绑定，可以将特定的执行计划固定下来，确保在集群重启或升级后，这些绑定关系依然稳定保持。具体操作可以参考官方文档 管理数据库/租户管理/租户常见操作/修改租户系统变量。
统计信息管理
-
定期的 ANALYZE TABLE 自动收集：对于核心表，建议采用定期的
ANALYZE TABLE 自动收集统计信息。这可以确保优化器在生成执行计划时使用最新的统计信息，从而提高计划的准确性。
-
手动收集并导入历史统计信息：在数据快速增长的分区表上，可以结合手动收集并导入历史统计信息的方式，平衡统计信息的准确性和收集开销。具体操作可以参考 阅读和管理 OceanBase 数据库 SQL 执行计划。
演进与验证
-
系统地比对和验证：在数据库大版本升级后，可以通过以下步骤系统地比对和验证核心SQL的执行计划是否变更：
-
基线对比：在升级前，记录下核心SQL的执行计划，作为基线。
-
升级后验证：升级后，重新运行这些SQL，并记录新的执行计划。
-
比对分析：将升级前后的执行计划进行比对，分析是否有变化。
-
告警机制：可以使用工具或脚本来自动化这一过程，并在检测到计划变更时触发告警。具体操作可以参考 管理数据库/租户管理/租户常见操作/修改租户系统变量。
方法论和工具链
-
方法论：
-
计划缓存：利用 OceanBase 的计划缓存机制，减少硬解析的频率，提高SQL执行效率。
-
性能监控：定期监控核心SQL的执行情况，及时发现性能问题。
-
变更管理：建立严格的变更管理流程，确保每次升级或数据量增长后，核心SQL的执行计划仍然稳定。
-
工具链：
-
DBMS_XPLAN 系统包：使用
DBMS_XPLAN 系统包来格式化和展示历史查询计划，便于分析和比对。
-
自动化脚本：编写自动化脚本来比对和验证执行计划的变化，并在检测到变化时触发告警。
通过上述方法和工具链，可以有效保障核心业务SQL性能的稳定性。
详情请参考:
- 执行计划管理
- SQL 调优典型场景和案例
- 计划缓存概述
- SQL 性能问题的典型场景和排查思路
- 常见的 SQL 调优方式
- 诊断实践：使用 DBMS_XPLAN 系统包进行性能诊断
1 个赞
关于OceanBase的问题，SQL确实是一个重要的考虑因素。在实际应用中，我发现SPM方法通常更有效。
1 个赞
