【 使用环境 】测试环境
【 OB or 其他组件 】 OB 执行计划
【 使用版本 】
【问题描述】老师好问题请教,看了SPM相关功能,请问一下如果spm执行计划中 有大账号执行计划,也有小账号的执行计划,
1.目前最新ob版本,sql执行过程中会根据大小账号选择对应的最优执行计划吗?还是建议应用程每次生成新的执行计划?比如select /* 随机数 +*/ from table_name?
2.可以修改 Baseline 计划的属性,比如 Fix 该计划,让 SQL 执行总是优先使用 Fixed 基线计划,好像也没解决问题?
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
5 个赞
论坛小助手
#5
SPM 与大小账号问题
根据您提供的信息和文档片段,针对您的问题解答如下:
-
SPM 执行计划中存在大账号和小账号的执行计划时的行为
根据 执行计划管理 → SPM 的执行机制 文档中的说明,在最新的 OceanBase 版本中,当 SQL 第一次生成的计划会被默认作为基线并被 ACCEPT。后续如果存在多个可以复现的基线(包括 FIXED 和 ACCEPTED 类型),系统会尝试使用这些已验证过的计划。然而,SPM 主要是基于 SQL Plan Baseline 来确保性能稳定,并不能智能地根据数据集特征(如账号的大小)来自动选择最优计划。因此,SQL 在执行过程中并不会根据大账号或小账号的特点主动选取不同的执行计划。
-
修改 Baseline 计划属性的影响
通过 ALTER_SQL_PLAN_BASELINE 可以修改某个或某些基线计划的状态为 FIXED,从而保证总是优先使用该固定状态下的执行计划,而不考虑是否有更好的新生成的计划。但是,正如您指出的那样,这种做法并不能根本解决因数据分布不均导致的大小账号问题,因为固定的计划可能对某一类查询有效,但对于另一类则不合适。例如,若某条 SQL 对于大量数据的处理非常高效(适合大账号),那么将其设定为 FIXED 后,虽然能够确保在面对大量数据时表现良好,但当遇到数据量相对较小的情况时,仍可能不是最优化的选择。
综上所述,虽然 SPM 可以帮助管理和维护有效的执行计划,减少计划退化带来的性能下降风险,但它并不是解决大小账号场景下执行计划非最佳选择的理想方案。对于这类问题,更建议从以下几个方面着手:
-
调整业务逻辑设计:尽量将大小账号的数据进行合理的拆分,减小单次查询涉及的数据范围。
-
实施查询限流策略:根据不同类型的请求控制其并发度,避免大规模操作同时发生。
-
利用索引及分区技术:合理设计表结构以及相关索引来优化读取效率。
-
手动绑定特定执行计划:对于已知会影响性能的关键 SQL 语句,可以通过
CREATE OUTLINE 等方式强制指定使用特定的执行路径。
详情请参考:
- 大小账号
- SQL 调优典型场景和案例
- SQL 性能问题的典型场景和排查思路
- 执行计划管理
- 事务控制概述
- 实时执行计划展示
3 个赞
非常感谢,还是要问一下ob数据层次后续会推出相关解决或应对方案吗?
1 个赞