OceanBase SQL 计划变化及相关问题

大小账号

大小账号介绍

大小账号在数据库场景下指的是在有数据倾斜的表上，数据比较明显地集中在一个值范围内，系统的流量也相对集中（通常是在数据集中的范围内），但同时有一小部分数据值与大部分值差别较大，且有少部分流量。系统流量的分布情况也可能集中在小账号，这也是一种大小账号场景，只是更少见一些。大小账号本身是一种特定的数据请求场景，而非问题。但是在这种特定的请求场景下，如果数据库在计划选择上导致流量大的请求走了相比较更差的计划，那么就有可能造成性能问题、故障，也就是经常会提到的大小账号问题。

业务存在数据倾斜的表，典型的比如说像中国大学生年龄表，大部分的年龄值集中在 17-22 岁，而少一部分年龄值分布在 30+ 岁。系统中的 SQL 流量也在大量访问大账号上。OceanBase 在 SQL 的计划生成时，依赖 SQL 首次进入系统的时候的参数值（这影响谓词选择的过滤性，最终影响代价计算后的计划选择）。由于系统的流量还是多在访问大账号，所以系统中首次 SQL 请求还是访问大账号的概率更大。如果不幸系统上线（或者业务上线）之后首次遇到的 SQL 请求就是小账号请求，那么有可能生成的计划就是小账号计划，这个计划在执行大账号请求的时候有可能是差的（比如相对更不优的索引、更不优的计划路径 etc.）。取决于造成的性能代价以及执行路径资源消耗，可能是会影响某一个业务场景慢，在并发量大的情况可能会造成 CPU 爆或者内存瓶颈等更严重的问题。如果在系统上线当下就不幸撞到了大小账号问题，通常能够直接引起足够的关注（还在系统上线的高度关注期），相关的运维人员也可以通过绑定计划、业务下线（限流）等更多手段来恢复系统并定位根因。一般在系统上线之前也建议进行更多地测试和流量预热等手段和方法来降低系统上线的风险。但如果系统已经平稳运行了一段时间，也有可能会因为一些原因造成计划变化、或者数据表本来是均匀分布，后来随业务变化数据变成倾斜形状等因素导致撞到了大小账号的问题。这种情况就需要系统管理员进行故障应急和问题定位，也通常没有办法事前预估问题。大小账号的问题触发在某种程度上来说是一个小概率事件，但这成为了一个专题问题主要是由于一旦发生有可能会造成性能问题，在有些（业务并发）场景下甚至会造成CPU持续打爆或者是内存持续用满的情况，造成系统可用性风险。

相关问题

大小账号问题在 OceanBase 数据库全版本上都有可能遇到。遇到大小账号的问题，既有可能是索引选错，也有可能是计划从好计划变成坏计划。

解决办法

如果是流量上线后首次执行生成计划对大部分流量不优的情况 OceanBase 数据库目前无法自动解决，需要运维识别、调优和风险消除。

如果是在系统运行的过程中，系统因为计划变化、数据变化等因素本来没问题撞到了大小账号的问题，OceanBase 数据库 V4.x 之前需要依赖绑定 outline 的方式来固定计划。也可以用刷计划的方式来应急。OceanBase 数据库 V4.x 主要依赖 SPM 能力来获得系统级别固定计划的能力。用户需要开启 SPM 功能。如果上述的解决办法没有起到作用，有可能是遇到了相关功能的 bug，需要联系 OceanBase 技术支持进行诊断解决。

计划变化

计划变化介绍

当每次一条新的 SQL 进入到 OceanBase 数据库时，都会生成一个新的执行计划。执行计划会被缓存，以避免相同 SQL 计划生成的代价。当计划还在缓存时，OceanBase 数据库的 SQL 引擎有能力保证 相同 的 SQL 能够使用缓存中的计划。通常计划缓存算法能够保证系统高频的 SQL 计划能够持续停留在缓存中。这样的机制能够保证整个系统的请求执行是更加稳定的状态。如果出现统计信息更新，schema 更新，计划不在计划缓存中等场景时，就有可能触发计划被重新生成。

OceanBase 数据库 V4.x之前由于技术实现的问题，在系统合并之后会统一刷统计信息，这会触发计划刷新。当计划被整体刷新后，所有来到 OceanBase 数据库的请求对系统而言都是”新 SQL“，这都会触发计划的重新生成。如果此次生成了一个新的计划，且对主流的 SQL 请求来讲是一个差的计划就有可能造成问题甚至是故障。

OceanBase 数据库 V4.x 之前没有系统级别固定计划的能力，如果用户确认某个 SQL 请求类型以及系统的主流业务负载比较稳定的前提下，建议可以使用绑定 outline 的手段来固定计划，达到系统计划稳定或者说性能稳定的目标。OceanBase 数据库 V4.x 推出了 SPM（SQL Plan Manager）能力（建议升级到 V4.2.1 BP6 及以上），使得 OceanBase 数据库有了系统级别自动化固定计划的能力。只要系统对一条 SQL 生成过好的计划，那么 SPM 有能力将该计划作为基线计划固定起来。但是请注意 SPM 不是万能的。如果系统从来没有生成过好的计划，SPM 并不能无中生有，只能在已经生成过的计划中固定一个相对更好的。而如果优化器从来没有生成过好的计划，通常也可以判定这是优化器的某个类型的缺陷，需要修复或者指定一些特定的 hint 来绕过。

计划变化本身只是描述因为各种原因同一条 SQL 在系统运行的过程中本来是计划 A，变成了计划 B 。这既有可能是从好计划变成了坏计划。也有可能是从坏计划变成了好计划。通常坏计划变成好计划是不被关注的，因为这意味着之前的坏计划没造成关注，变成好计划之后也带来了收益。而好计划变成坏计划是经常被关注的，因为这可能意味着本来运行平稳的系统，甚至用户感觉也没有负载的提高，却变慢了，甚至造成故障了。

在此段落中，多次提到的 相同 SQL 是指 SQL 的长相框架相同，比如都是select c1, c2 from t1 where c1 =?，多次执行?的取值不同也是长相同的SQL。另外数据访问的位置相同，如本地访问和远程访问就是不同的 SQL。对应到系统里，相同的 SQL_ID 就意味着相同的 SQL。

相关问题

计划变化造成好计划变成坏计划可能造成系统性能问题或者是资源侵占问题。计划变化造成的问题场景常见的有大小账号问题、索引选错、计划路径选错等。

解决办法

由于 OceanBase 数据库 V4.x之合并刷统计信息造成刷计划诱发的计划变化问题在 OceanBase 数据库 V4.x 之前产品不会再做架构改动。如果因为计划变化造成了问题，需要进行 outline 绑定进行计划固定。OceanBase 数据库 V4.x 版本之后，SQL统计信息剥离了合并系统行为，不会再出现合并刷计划的情况。

由于其他的原因造成计划非预期变化的情况，在 OceanBase 数据库 V4.x 之前需要绑定 outline 固定计划应急。在 OceanBase 数据库 V4.x 之后开启 SPM 能力后可以拥有系统级固定计划的能力。如果上述的解决办法没有起到作用，有可能是遇到了相关功能的 bug，需要联系 OceanBase 技术支持进行诊断解决。当遇到索引选错的情况，如果有可能创建出更好的索引，这通常也是一个选项，例如：where c1 = ? and c2 = ? and c3 = ? SQL 在索引 (c1, c3) 和 （c2, c3） 之间跳动，可以建索引 (c1, c2,c3) ，根据 OceanBase 剪枝规则，前两个索引在 CBO 前就被剪枝掉了，AccessPatch 不会轻易变化。

OCP SQL 自愈

当用户遇到 SQL 导致 CPU 持续飙高的场景时，通常需要采用限流、定位问题 SQL、刷计划、固定计划等操作来进行应急止血。并且这些操作逻辑上应该能解决大部分场景中遇到的问题。因此OCP的诊断模块将问题诊断以及故障应急的步骤进行了标准化，自动化，从而达到提速故障应急效率的目标。OCP 的 SQL 自愈能力在 OCP V4.2.1 及以上提供该功能（默认打开），OCP V3.1.X 及以下版本升级上来的，需要手动开启该告警。公有云的自治服务根因诊断已经具备一定的问题定位应急能力，能多 SQL 治理能力规划中，详情参考更多信息。诊断会判断是否有 CPU 持续飙高情况（默认 90% 以上），如果有单条 SQL 占用 CPU 较高（默认 15%）且伴随有计划恶化、性能下降的情况，OCP 提供告警配置接口将此类问题告警出来，并且提供一键按钮可以分别执行限流、刷计划（定位好问题 SQL 的刷计划）、绑定 outline 能力。大致的诊断逻辑如下：

• 如果 server CPU 高且特定 SQL 的 CPU 占比过高：OCP 提供告警诊断能力定位问题 SQL，并提示客户可以做应急限流。

• 如果 server CPU 高且特定 SQL 的 CPU 占比过高，且定位 SQL 的执行性能下降：OCP 提供告警诊断能力定位问题 SQL，并提示客户可以做刷新定位问题 SQL 的 PlanCache 动作（可自动执行）以及限流应急动作。

• 如果 server CPU 高且特定 SQL 的CPU 占比过高，且定位SQL的执行计划恶化：OCP 提供告警诊断能力定位问题 SQL，并提示客户可以做刷新定位问题 SQL 的 PlanCache 动作（可自动执行）、限流应急动、以及绑定 outline 固定计划动作。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 所有版本。