遇到一个现象：某张表数据量变化比较大，执行计划选了个明显不合适的索引，手动 ANALYZE TABLE 后就正常了。
想请教：
- OB 的自动统计信息收集是默认开启的吗？触发条件是什么？
-
enable_sql_plan_baseline或 plan cache 会不会导致旧计划一直复用？ - 生产上怎么监控“统计信息过期”这类问题？
有相关经验的朋友指点下。
1 个赞
OB 的自动统计信息收集机制
根据文档中的信息，OceanBase 数据库默认是开启自动统计信息收集的。触发自动统计信息收集的主要依据是表数据的变化情况。
- 默认开启：OceanBase 自动统计信息收集功能默认是启用的。
- 触发条件：如果某张表的数据在上一次统计信息收集之后发生了较大的增、删、改变化，默认情况下当这些操作的比例超过 10% 时，就会触发该表的统计信息重新收集。这个阈值可以通过配置进行调整。对于分区表来说，判断是否需要更新统计信息是以分区为单位来进行的，即如果某个分区的数据变化达到了设置的阈值，那么该分区的统计信息将会被重新收集。
- 更多关于自动统计信息收集的工作机制，可以参考以下内容：
SQL 计划基线和计划缓存的影响
-
enable_sql_plan_baseline 或 plan cache：这两个特性主要是为了提高查询性能的一致性和稳定性，通过保存历史上的良好执行计划来避免因统计信息改变导致的执行计划波动。如果开启了
SQL_PLAN_BASELINE或者使用了plan cache功能，在某些情况下确实可能会使得优化器继续选择基于旧统计信息生成的执行计划，即使当前统计信息已经更新。这通常是因为系统认为历史上的执行计划表现更好，除非手动刷新计划基线或清空计划缓存。
生产环境中监控“统计信息过期”的方法
-
查询相关视图：可以通过查询数据库中的一些特定视图来监测统计信息的状态及其收集情况。例如，Oracle 模式下可以查看
ALL_TAB_MODIFICATIONS或DBA_TAB_MODIFICATIONS视图来获取各表的 DML 操作次数；而无论是 Oracle 还是 MySQL 模式，都可以利用OCEANBASE.DBA_SCHEDULER_JOBS和OCEANBASE.DBA_SCHEDULER_WINDOWS（针对 MySQL 模式）等视图了解维护窗口任务（包括自动统计信息收集任务）的执行详情如上次运行时间、下次预定时间以及失败计数等。 - 更多细节，请参阅：
希望以上信息能帮助您理解和解决遇到的问题！如果有更具体的需求或问题，请随时提问。
检索到的文档如下: