提问背景
OceanBase的优化器基于代价选择执行计划，索引统计信息（如直方图）的准确性直接影响计划质量。当数据分布倾斜或查询条件复杂时，可能选错索引。此外，执行计划缓存虽然能减少解析开销，但若缓存计划不适合后续参数，反而导致性能下降。用户急需了解如何监控和干预计划生成。
具体问题
- OceanBase如何收集统计信息？是否支持自动更新统计信息？对于分区表，统计信息是全局维护还是分区级维护？
- 当发现某条SQL使用了错误的索引，是否有类似Oracle的SQL Profile或Outlines功能可以稳定计划？
- 执行计划缓存的失效策略是什么？当表结构或统计信息变更时，缓存计划会自动失效吗？如何手动清理特定SQL的缓存计划？
- 是否存在类似MySQL的optimizer_switch开关，可以调整优化器行为（如索引合并、MRR）？
问题价值
SQL性能调优是DBA日常工作重点，该问题直接触及优化器内核机制，帮助用户提升诊断和优化能力，尤其适合复杂查询场景。
2 个赞
论坛小助手
#6
OceanBase的优化器和执行计划管理有以下几个要点：
-
统计信息收集：
- 在V4.2.0版本，OceanBase支持了统计信息收集监控诊断功能，可以监控统计信息收集的状态并反馈收集情况。对于数据分布变化导致的执行计划不佳问题，OceanBase优化器依赖实时有效的统计信息来生成最优执行计划。这些统计信息包括表和列的信息，如行数、数据分布等，直方图信息也是其中一部分。在V4.0版本之后，统计信息收集与每日合并解耦，可以在任意时间手动触发，也可以自动定期更新。对于分区表，统计信息可以在全局层面和分区级别分别维护，以适应不同的数据分布特性。
-
索引选择性与SQL Profile：
- OceanBase通过直方图来改善索引选择性问题，当数据存在倾斜时，优化器可以根据直方图信息做出更准确的行数估计。对于错误的索引选择，虽然OceanBase目前没有像Oracle那样的SQL Profile或Outlines功能，但可以通过手动绑定计划（Hint）来强制使用特定的执行计划，或者通过调整索引设计来避免错误的索引选择。
-
执行计划缓存管理：
- 执行计划缓存是为了避免每次SQL执行时的硬解析开销，提高SQL的响应速度。当SQL第一次执行时，优化器会生成执行计划并将其缓存。后续相同的SQL请求可以直接使用缓存中的计划。如果表结构或统计信息发生变更，缓存中的计划会自动失效。此外，用户可以通过系统命令手动清理特定SQL的缓存计划，以应对特定场景下的性能问题。
-
优化器行为调整：
- OceanBase提供了一些参数来调整优化器的行为，类似于MySQL的optimizer_switch开关。例如，可以通过设置参数来控制索引合并、多范围读（MRR）等优化器特性。
具体信息可参考以下文档:
- 统计信息和估行机制概述
- OceanBase 数据库性能的影响因素
- SQL 性能问题的典型场景和排查思路
- 常见的 SQL 调优方式
