文章详细介绍了Oceanbase数据库的多种合并策略，包括智能轮转合并、非智能轮转合并、手动合并和自动非轮转合并，以及这些策略如何在不影响业务的情况下进行并发度控制。同时，文章也提到了执行计划的重要角色，如ID、OPERATOR、EST.ROWS和COST的含义，以及计划缓存的管理和淘汰机制，包括自动和手动淘汰的情况。此外，还讨论了查询改写和Outline绑定对执行计划的影响。
21 智能轮转合并
1.关闭手动合并alter system set enable_manual_merge = false;
2.开启轮转合并alter system set enable_merge_by_turn = true;
RS根据一定策略依次调度 zone合并,并进行并发度控制
线上部署最常用的合并调度方案，轮转合并的过程中，RS会保证尽量不影响业务的请求，通过切leader的方式， 将用户读写路由到不在合并的zone中;
22. 非智能轮转合并 （注意rs的功能，以及退化成智能轮转合并）
自动指定顺序的轮转合并
用户直接指定轮转的顺序， RS只负责并发度控制
一种特殊的轮转合并策略，一般不会使用，只有当智能轮转合并不满足业务需求的情况下，才需要为集群定制特殊的合并调度策略
在zone成员发生变更的情况下，自动指定顺序的轮转合并会失效，退化成智能轮转合并
23.手动合并 （按zone）
用户通过sql命令指定zone 开始合并，需要用户自己控制并发度
1.开启手动合并alter system set enable_manual_merge = true;
2.用户自主决定合并顺序和并发度，通过 SQL命令调度zone合并，比如调度z1开始 合并:alter system start merge zone = 'z1';
纯手工操作，一般在业务每日合并出现问题、需要人工介入的情况下使用
一旦开启，一次合并都需要用户主动调度，除非关掉手动合并，开启自动合并
24.
自动非轮转合并
所有zone一起开始合并， 没有并发度控制
1.关闭手动合并alter system set enable_manual_merge = false;
2.关闭轮转合并alter system set enable_merge_by_turn = false;
当业务量比较小的情况下，合并中的zone也能支持业务流量时，则可以开启自动非轮转合并，这样做能够避免 用户跨表join请求变成分布式跨机查询
每日合并会对业务请求产生一定的性能影响，需要业务进行确认
25.
每条语句只有一个执行计划缓存
26. 快速参数化（多选题）
执行计划快速参数化-常量不能参数化的场景
n 所有 ORDER BY 后常量(例如"ORDER BY 1,2;")
n 所有 GROUP BY 后常量(例如"GROUP BY 1,2;")
n LIMIT 后常量(例如"LIMIT 5;")
n 被物化的参数精度数字(例如"NUMBER(10,2);")
n select投影列中常量(例如"select 1 as id from tab;")
n 作为格式串的字符串常量(例如"DATE_FORMAT('2006-06-00', '%d'); "里面的"%d")
n 函数输入参数中，影响函数结果或带有隐含信息并最终影响执行计划的常量(例如"CAST(999.88 as NUMBER(2,1))" 中的"NUMBER(2,1)"，或者"SUBSTR('abcd', 1, 2)"中的"1, 2"，或者"SELECT UNIX_TIMESTAMP('2015-11-13 10:20:19.012');" 里面的"2015-11-13 10:20:19.012"，指定输入时间戳同时，隐含指定了函数处理的精度值为毫秒)
27.
执行计划
|ID|OPERATOR |NAME|EST. ROWS|COST| 每一列的含义，注意cost， 单位不是bytes，是微秒
ID 执行树按照前序遍历的方式得到的编 号(从0开始)
OPERATOR 操作算子的名称
NAME 对应表操作的表名(索引名)
EST. ROWS 估算的该操作算子的输出行数
COST 该操作算子的执行代价(微秒)
28.
Oceanbase目前只实现了一个基于代价的查询改写（or-expansion）
Or-expansion把一个查询改写成若干个用union组成的子查询，这个改写可能会给每个子查询提供更优的优化空间，但是也会导致多个子查询的执行，
所以这个改写需要基于代价去判断。通常来说，Or-expansion的改写主要有如下三个作用:
允许每个分支使用不同的索引来加速查询
允许每个分支使用不同的连接算法来加速查询，避免使用笛卡尔连接
允许每个分支分别消除排序，更加快速的获取top-k结果
29.
自动淘汰是指当计划缓存占用的内存达到了需要淘汰计划的内存上限(即淘汰计划的高水位线)时，对计划缓存中的计划执行自动淘汰。
触发执行计划淘汰的条件
每隔一段时间(具体时间间隔由配置项 plan_cache_evict_interval 设置)系统会自动检查不同租户在不同服务器 上的计划缓存，并判断是否需要执行计划淘汰。如果某个计划缓存占用的内存超过该租户设置的淘汰计划的高水位 线，则会触发计划缓存淘汰
执行计划淘汰策略
当触发计划缓存淘汰后，优先淘汰最久没被使用的执行计划，淘汰一部分执行计划后，当计划缓存使用的内存为该
租户设置的淘汰计划的低水位线时，停止淘汰
优先淘汰最久没被使用的执行计划，影响淘汰策略的参数和变量如下:
plan_cache_evict_interval(parameter):检查执行计划是否需要淘汰的间隔时间 30秒 （注意）
ob_plan_cache_percentage(variable):计划缓存可使用内存占租户内存的百分比 (最多可使用内存为:租 户内存上限 * ob_plan_cache_percentage/100)
ob_plan_cache_evict_high_percentage (variable) :计划缓存使用率(百分比)达到多少时，触发计划缓 存的淘汰
ob_plan_cache_evict_low_percentage (variable) :计划缓存使用率(百分比)达到多少时，停止计划缓存 的淘汰
重点： 如果淘汰速度没有新计划生成速度快，计划缓存使用内存达到内存上限绝对值1G时，将不再往计划缓存中添加新计划，直到淘汰后使用的内存小于1G才会添加新计划到计划缓存中
手动淘汰是指强制将计划缓存中计划进行删除。现在支持指定不同租户对应的当前服务器或全部服务器中计划缓存全部 删除，SQL 语句如下:
obclient>ALTER SYSTEM FLUSH PLAN CACHE [tenant_list] [global]
其中 tenant_list 和 global 为可选字段，使用说明如下:
tenant_list 格式为 tenant = 'tenant_name, tenant_name....'。如果没有指定 tenant_list，则清空所有租户的计划 缓存。
反之，则只清空特定租户的计划缓存
如果没有指定 global，则清空本机的计划缓存。反之，则清空该租户所在的所有服务器上的计划缓存
如下场景会导致执行计划失效，需要对执行计划进行刷新:
n SQL 中涉及表的 Schema 变更时(比如添加索引、删除或增加列等)，该 SQL 在计划缓存中所对应的执行计划将被 刷新
n SQL 中涉及重新收集表的统计信息时，该 SQL 在计划缓存中所对应的执行计划会被刷新。由于 OceanBase 数据库在 数据合并时会统一进行统计信息的收集，因此在每次进行合并后，计划缓存中所有计划将被刷新
n SQL进行outline计划绑定变更时，该SQL对应的执行计划会被刷新，更新为按绑定的outline生成的执行计划
系统变量控制
当 ob_enable_plan_cache 设置为 TURE 时，表示 SQL 请求可以使用计划缓存;设置为 FALSE 时，表示 SQL 请 求不使用计划缓存。默认为 TURE。
此系统变量可被设置为 Session 级别或者 Global 级别
Hint 控制
使用 Hint 语句 /+USE_PLAN_CACHE(NONE)/ 表示不使用计划缓存 l 使用 Hint 语句 /+USE_PLAN_CACHE(DEFAULT)/ 表示使用计划缓存
1：表示 Local Plan
2：表示 Remote Plan
3：表示 Distribute
30.
OceanBase 数据库通过 SQL_ID 区分不同的 SQL，而 SQL_ID 是通过 SQL_TEXT 取 MD5 加密得到的
在实际生产系统中，推荐通过 SQL_ID 进行 Outline 绑定。
当 SQL_ID 相同时，使用 SQL_TEXT 方式创建的 Outline 会覆盖 SQL_ID 方式创建的 Outline
plan_cache_plan_stat 中可以存在多条 sql_id
7577
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
