如何分析动态采样引起的计划不稳定 | OceanBase SQL 调优实践

news2025/7/19 16:28:36
这篇博客涉及两个知识点,一个是动态采样,另一个是 DAS 执行。

用户的问题和相关结论

我们看看用户在OceanBase 社区论坛发帖中提出的疑问及其所得出的结论。

问题:收集统计信息之前,为什么会出现计划不稳定的情况?

原帖详见:索引和统计信息问题咨询 - OceanBase - 社区问答- OceanBase社区-分布式数据库

结论:若尚未收集过统计信息,为了创建更优的执行计划,优化器会对表数据进行动态采样。动态采样是在计划生成阶段对数据库对象进行的采样,通过此方式估算行数,并将这些估算值用于代价计算模型中。由于动态采样过程中每次所选的样本数据块具有一定的随机性质,即便表中的数据保持不变,动态采样的结果也可能有所不同,因此可能导致生成不同的执行计划。

用户反馈的问题

下面是这个用户给的计划不稳定的例子,感兴趣的同学可以继续往下看:

第一个问题

用户问的第一个问题就是:为什么收集统计信息前,计划不稳定?

用户的环境信息:三 zone 三副本,各个副本的 leader 打散在三个分区上。

表定义长这样:

CREATE TABLE `test` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `did` varchar(64) DEFAULT NULL COMMENT 'did',
  `dxm_uuid` varchar(64) DEFAULT NULL COMMENT 'uuid',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_did_uuid` (`did`, `uuid`) BLOCK_SIZE 16384 GLOBAL,
  KEY `I_create_time` (`create_time`) BLOCK_SIZE 16384 LOCAL,
  KEY `I_update_time` (`update_time`) BLOCK_SIZE 16384 LOCAL
) REPLICA_NUM = 3
 partition by hash(id) PARTITIONS 30;

一张三十个分区的分区表,上面有三个索引,一个没有分区的 global index,两个和主表一样有三十个分区的 local index。

执行的 SQL 长这样,十分简单:

SELECT
  uuid
FROM
  test
WHERE
  did = ?
ORDER BY
  update_time DESC
LIMIT
  ?

如果没有统计信息,根据不同的动态采样结果,显而易见,可能会出现两种计划。

第一种是走 I_update_time 这个 local index,好处是可以利用这个索引的有序性,优化 ORDER BY update_time DESC 这个排序的动作,消除了各个分区内的排序(个人理解三号算子的 top n sort 不需要真正进行 sort,只需要做 top n 就够了),计划长这样:

第二种是走 unique_did_uuid 这个 global index,好处是满足 did = ? 这个过滤条件的数据,可以在索引上被快速定位,计划长这样:

这里用户反馈的是:如果生成第一种走 I_update_time 这个 local index 的计划,就会慢。

如果生成第二种走 unique_did_uuid 这个 global index 的计划,就会快。

1718552204

因为没有统计信息,所以优化器只能根据动态采样得来的部分数据,算出这两种计划的代价,然后生成代价更低的计划。

即使表中的数据没有发生过变化,因为每次动态采样的数据因为有一定的随机性,会采样到不同的数据,所以可能导致生成的计划不稳定。如果采样到一批比较极端的不能代表整体数据特征的数据,就会导致生成不优的计划。

动态采样的介绍,详见官网链接:https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000822131,咱们这里不多啰嗦。

第二个问题

用户问的第二个问题是:收集了统计信息之后,为什么就能稳定生成第二种更优的本地计划了?

这也是个有意思的问题,需要咱们再来重新回顾一遍问题的背景。

用户的环境信息:三 zone 三副本,各个副本的 leader 打散在三个分区上。

表定义长这样:

CREATE TABLE `test` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `did` varchar(64) DEFAULT NULL COMMENT 'did',
  `dxm_uuid` varchar(64) DEFAULT NULL COMMENT 'uuid',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_did_uuid` (`did`, `uuid`) BLOCK_SIZE 16384 GLOBAL,
  KEY `I_create_time` (`create_time`) BLOCK_SIZE 16384 LOCAL,
  KEY `I_update_time` (`update_time`) BLOCK_SIZE 16384 LOCAL
) REPLICA_NUM = 3
 partition by hash(id) PARTITIONS 30;

一张三十个分区的分区表,上面有三个索引,一个没有分区的 global index,两个和主表一样有三十个分区的 local index。

执行的 SQL 长这样,十分简单:

SELECT
  uuid
FROM
  test
WHERE
  did = ?
ORDER BY
  update_time DESC
LIMIT
  ?

因为这条 SQL 涉及的表是分区表,各个分区的主副本都被打散在了不同的 zone 里,并且 SQL 的过滤条件又不包含分区键,所以 proxy 这个时候是没办法知道要怎么对这条 SQL 进行路由的。这时候 proxy 就会随机路由到任意一台节点上。

但是收集完统计信息之后,发现可以稳定选择走 unique_did_uuid 这个 global index,计划长这样:

看上去没有 remote xxx 算子和 exchange xxx 算子,不是远程计划和分布式计划,那么这就是个本地计划。

这个计划虽然是本地计划,但是实际也有数据的网络传输。因为 SQL 需要根据 update_time 列进行排序,global index 中并没有这个列的数据,所以过滤完之后,肯定还需要回主表(计划里也可以看到 is_index_back = true)去拿 update_time 列的值,一定还是会走网络的。

不过这个本地计划里的网络传输,和上一个计划有明确的 exchange 算子表示网络传输有所不同,这个计划里的网络传输被封到了一号算子里。一号算子是 DISTRIBUTED TABLE SCAN,含义是 TABLE SCAN 走了 DAS 执行。

大家可以简单地把 DAS 理解成是一种特殊场景下,对网络传输的优化。

DAS 不需要像 remote 或者 exchange 算子一样在网络中把复杂的 SQL 或者子计划在节点间传来传去,而是直接跟存储层交互,通过 RPC 拉取到存储层的数据。

DAS 一般会出现在简单的点查,或者全局索引回表中(刚好就是用户的场景,did = ? 是点查,并且还有全局索引的回表)。DAS 可以通过特殊的 RPC 和存储层直接进行远程数据的交互,所以可以减少在网络里传输 SQL 和子计划的开销。在这两种场景下,通过 DAS 的方式进行数据的网络传输,资源消耗是最小的。

DAS 执行的介绍详见官网链接:https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000217873,咱们依然不在这里多啰嗦。

我们以 proxy 转发 SQL 到 zone2 这台 observer 上为例,那么 zone2 上这台 observer 就会通过 DAS 发 RPC 拉取另外几个节点上的主表数据,进行全局索引回表。

我们以 proxy 转发 SQL 到 zone1 这台 observer 上为例,那么 zone1 上这台 observer 首先会通过 DAS 发 RPC 直接拉取 zone2 上 global index 主副本上的经过过滤之后的数据(过滤条件也一起下压过去了),然后再通过 DAS 发 RPC 拉取另外几个节点上的主表数据,进行全局索引回表。

所以无论 proxy 把 SQL 路由到哪个节点,这条 SQL 中网络传输的动作,都被封到一号 DISTRIBUTED TABLE SCAN 算子里了(一号算子通过 DAS 执行完成了全部的网络传输),因此可以生成稳定的计划。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2379160.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

如何实现RTSP和RTMP低至100-200ms的延迟:直播SDK的技术突破

在实时音视频传输中,低延迟是直播应用的核心技术要求之一。无论是在线教育、远程医疗,还是实时互动直播,延迟过大会影响用户体验,甚至导致应用无法正常使用。大牛直播SDK(SmartMediaKit)在RTSP和RTMP播放器…

symfonos: 2靶场

symfonos: 2 来自 <https://www.vulnhub.com/entry/symfonos-2,331/> 1&#xff0c;将两台虚拟机网络连接都改为NAT模式 2&#xff0c;攻击机上做namp局域网扫描发现靶机 nmap -sn 192.168.23.0/24 那么攻击机IP为192.168.23.182&#xff0c;靶场IP192.168.23.253 3&…

【图像生成大模型】Step-Video-T2V:下一代文本到视频生成技术

Step-Video-T2V&#xff1a;下一代文本到视频生成技术 引言Step-Video-T2V 项目概述核心技术1. 视频变分自编码器&#xff08;Video-VAE&#xff09;2. 3D 全注意力扩散 Transformer&#xff08;DiT w/ 3D Full Attention&#xff09;3. 视频直接偏好优化&#xff08;Video-DPO…

深度学习推理引擎---ONNX Runtime

一、基础概念 1. 什么是ONNX Runtime&#xff1f; 定位&#xff1a;由微软开发的跨平台推理引擎&#xff0c;专为优化ONNX&#xff08;Open Neural Network Exchange&#xff09;模型的推理性能设计。目标&#xff1a;提供高效、可扩展的推理能力&#xff0c;支持从云到边缘的…

VueUse/Core:提升Vue开发效率的实用工具库

文章目录 引言什么是VueUse/Core&#xff1f;为什么选择VueUse/Core&#xff1f;核心功能详解1. 状态管理2. 元素操作3. 实用工具函数4. 浏览器API封装5. 传感器相关 实战示例&#xff1a;构建一个拖拽上传组件性能优化技巧与原生实现对比常见问题解答总结 引言 在现代前端开发…

【论文阅读】A Survey on Multimodal Large Language Models

目录 前言一、 背景与核心概念1-1、多模态大语言模型&#xff08;MLLMs&#xff09;的定义 二、MLLMs的架构设计2-1、三大核心模块2-2、架构优化趋势 三、训练策略与数据3-1、 三阶段训练流程 四、 评估方法4-1、 闭集评估&#xff08;Closed-set&#xff09;4-2、开集评估&…

vue3 elementplus tabs切换实现

Tabs 标签页 | Element Plus <template><!-- editableTabsValue 是当前tab 的 name --><el-tabsv-model"editableTabsValue"type"border-card"editableedit"handleTabsEdit"><!-- 这个是标签面板 面板数据 遍历 editableT…

Linux的进程概念

目录 1、冯诺依曼体系结构 2、操作系统(Operating System) 2.1 基本概念 ​编辑 2.2 目的 3、Linux的进程 3.1 基本概念 3.1.1 PCB 3.1.2 struct task_struct 3.1.3 进程的定义 3.2 基本操作 3.2.1 查看进程 3.2.2 初识fork 3.3 进程状态 3.3.1 操作系统的进程状…

计算机单个进程内存布局的基本结构

这张图片展示了一个计算机内存布局的基本结构&#xff0c;从低地址&#xff08;0x00000000&#xff09;到高地址&#xff08;0xFFFFFFFF&#xff09;依次分布着不同的内存区域。 代码段 这是程序代码在内存中的存储区域。它包含了一系列的指令&#xff0c;这些指令是计算机执行…

我的电赛(简易的波形发生器大一暑假回顾)

DDS算法&#xff1a;当时是用了一款AD9833芯片搭配外接电路实现了一个波形发生&#xff0c;配合stm32f103芯片实现一个幅度、频率、显示的功能&#xff1b; 在这个过程中&#xff0c;也学会了一些控制算法&#xff1b;就比如DDS算法&#xff0c;当时做了一些了解&#xff0c;可…

算法题(149):矩阵消除游戏

审题&#xff1a; 本题需要我们找到消除矩阵行与列后可以获得的最大权值 思路&#xff1a; 方法一&#xff1a;贪心二进制枚举 这里的矩阵消除时&#xff0c;行与列的消除会互相影响&#xff0c;所以如果我们先统计所有行和列的总和&#xff0c;然后选择消除最大的那一行/列&am…

printf函数参数与入栈顺序

01. printf()的核心功能 作用&#xff1a;将 格式化数据 输出到 标准输出&#xff08;stdout&#xff09;&#xff0c;支持多种数据类型和格式控制。 int printf(const char *format, ...);参数&#xff1a; format&#xff1a;格式字符串,字符串或%开头格式符...&#xff1a;…

仿生眼机器人(人脸跟踪版)系列之一

文章不介绍具体参数&#xff0c;有需求可去网上搜索。 特别声明&#xff1a;不论年龄&#xff0c;不看学历。既然你对这个领域的东西感兴趣&#xff0c;就应该不断培养自己提出问题、思考问题、探索答案的能力。 提出问题&#xff1a;提出问题时&#xff0c;应说明是哪款产品&a…

Go语言语法---输入控制

文章目录 1. fmt包读取输入1.1. 读取单个值1.2. 读取多个值 2. 格式化输入控制 在Go语言中&#xff0c;控制输入主要涉及从标准输入(键盘)或文件等来源读取数据。以下是几种常见的输入控制方法&#xff1a; 1. fmt包读取输入 fmt包中的Scan和Scanln函数都可以读取输入&#xf…

CSS- 4.3 绝对定位(position: absolute)学校官网导航栏实例

本系列可作为前端学习系列的笔记&#xff0c;代码的运行环境是在HBuilder中&#xff0c;小编会将代码复制下来&#xff0c;大家复制下来就可以练习了&#xff0c;方便大家学习。 HTML系列文章 已经收录在前端专栏&#xff0c;有需要的宝宝们可以点击前端专栏查看&#xff01; 点…

Seata源码—6.Seata AT模式的数据源代理一

大纲 1.Seata的Resource资源接口源码 2.Seata数据源连接池代理的实现源码 3.Client向Server发起注册RM的源码 4.Client向Server注册RM时的交互源码 5.数据源连接代理与SQL句柄代理的初始化源码 6.Seata基于SQL句柄代理执行SQL的源码 7.执行SQL语句前取消自动提交事务的源…

计算机科技笔记: 容错计算机设计05 n模冗余系统 TMR 三模冗余系统

NMR&#xff08;N-Modular Redundancy&#xff0c;N 模冗余&#xff09;是一种通用的容错设计架构&#xff0c;通过引入 N 个冗余模块&#xff08;N ≥ 3 且为奇数&#xff09;&#xff0c;并采用多数投票机制&#xff0c;来提升系统的容错能力与可靠性。单个模块如果可靠性小于…

Spring Boot 与 RabbitMQ 的深度集成实践(一)

引言 ** 在当今的分布式系统架构中&#xff0c;随着业务复杂度的不断提升以及系统规模的持续扩张&#xff0c;如何实现系统组件之间高效、可靠的通信成为了关键问题。消息队列作为一种重要的中间件技术&#xff0c;应运而生并发挥着举足轻重的作用。 消息队列的核心价值在于其…

黑马程序员2024新版C++笔记 第2章 语句

1.if逻辑判断语句 语法主体&#xff1a; if(要执行的判断&#xff0c;结果是bool型){判断结果是true会执行的代码; } 2.AI大模型辅助编程 在Clion中搜索并安装对应插件&#xff1a; 右上角齿轮点击后找到插件(TRONGYI LINGMA和IFLYCODE)安装后重启ide即可。 重启后会有通义登…

前端动画库 Anime.js 的V4 版本,兼容 Vue、React

前端动画库 Anime.js 更新了 V4 版本&#xff0c;并对其官网进行了全面更新&#xff0c;增加了许多令人惊艳的效果&#xff0c;尤其是时间轴动画效果&#xff0c;让开发者可以更精确地控制动画节奏。 这一版本的发布不仅带来了全新的模块化 API 和显著的性能提升&#xff0c;还…