尧图网页设计 
简介一份面向2025年全国大学生计算机系统能力大赛第五届OceanBase数据库大赛的完整项目资料包适合参赛学生、数据库爱好者以及希望深入分布式数据库内核的开发者参考。资源共包含2000个文件主要类型为C/C源文件与头文件、Markdown说明文档、JSON配置文件、Python辅助脚本及测试样例同时包含构建脚本、Git版本控制对象、预期输出及配置模板代码与文档比例均衡整体约113.94MB。该资料包已有50人学习下载。内容覆盖比赛所需的基础代码、文档说明、测试用例与工具脚本可以帮助参赛队伍快速理解OceanBase核心实现、掌握竞赛考点也可作为高校数据库课程设计和系统能力训练的有力素材对于研究数据库存储引擎、事务处理等模块的开发者同样具有参考价值。1. OceanBase 备赛资源拆解先解决“集群起不来”再谈调优很多第一次碰 OceanBase 的同学不是被 SQL 题难倒而是卡在最前面集群起不来、租户建不出来、写个备份脚本连上对象存储又被签名错误打回。这个竞赛表面考 SQL 和调优实际先考你能不能把一套分布式数据库拉到能跑的状态。我拆这份第五届 OceanBase 数据库大赛备赛资源时最大的感受是它没有按官方文档顺序堆知识而是按一条比赛真实路径排下来——从 obd 部署、租户资源隔离到 Minio 对象存储备份、执行计划调优全部落在具体命令和参数上连翻车现场都给了对照解法。适合两类人一类是准备参赛、想省下大量调研时间的学生另一类是想快速上手 OceanBase、拿竞赛题当场景练手的从业者。这篇笔记会把环境部署、核心功能、避坑记录和调优验证依次过一遍你在本地机器上照着走就能复现。2. 环境搭建用 obd 拉起 OceanBase把备份落到 Minio2.1 为什么竞赛环境首选 obd 单机部署OceanBase 是分布式架构生产环境至少三台机器起步但竞赛场景绝大多数题目不要求跨机分布式能力反而更看重你能否快速起一个可用集群。常见做法是用 obdOceanBase Deployer在一台主机上部署一个 observer 实例CPU、内存、日志盘都按本机配置收缩。obd 的价值在于把配置生成、进程拉起、状态检查都封装成命令你不用手工去写 systemd 脚本也不用担心 observer 进程以什么用户启动、数据目录建在哪这种琐碎问题。另一个选择是直接下载 RPM 包手动部署但我一般不建议在竞赛准备阶段这么做。手动部署需要自己管理 observer 进程、初始化系统租户、处理目录权限任何一个环节出错都会浪费半天。用 obd 的好处是你少踩一半环境坑把精力留给后面真正拉分的 SQL 和调优题。需要提醒的是obd 只是部署工具不等于 OceanBase 本身后续所有 SQL 操作还是在 obclient 里完成。2.2 部署命令与关键参数先装 obd。这里的 ob-deployer 是管理端工具装好后用这里写好的最小配置拉一个单机实例# 安装 obd不同发行版用对应包管理器这里以 CentOS 系的 yum 为例 sudo yum install -y ob-deployer # 用 here-doc 生成最小集群配置单机跑一个 observer cat obtest.yaml EOF oceanbase-ce: servers: - 127.0.0.1 global: home_path: /home/admin/oceanbase memory_limit: 8G system_memory: 1G datafile_size: 10G log_disk_size: 10G EOF # 根据配置自动生成集群并启动 obd cluster autodeploy ob_test -c obtest.yaml obd cluster start ob_testautodeploy 会读取 obtest.yaml 里的参数生成完整的 observer 配置并拉起进程。memory_limit 控制 observer 进程可使用的总内存8G 是比赛常见配置如果你的机器只有 8G 内存把这个值压到 4G同时把 system_memory 降到 1G 以下。datafile_size 是数据文件预分配大小10G 在本地磁盘够用log_disk_size 是日志盘空间太小会导致 clog 写满后集群停止写入这个参数宁可给大一点。启动完成后验证一下 observer 状态obclient -h127.0.0.1 -P2881 -urootsys -p默认端口 2881 是 SQL 连接端口2882 是 RPC 端口。rootsys 是系统租户的管理员账号首次登录密码在 obd 部署时如果没有显式指定通常为空或按部署输出提示设置。登录后执行一句确认SELECT * FROM DBA_OB_SERVERS\G能看到 observer 的 status、start_service_time 等字段status 为 ACTIVE 说明集群已经可用了。这一步通过后再继续建租户顺序别反很多同学一上来就建表结果连接的是 sys 租户后面所有业务租户的题全白做。2.3 把 Minio 接进备份链路比赛里经常给一个 Minio 或兼容 S3 的对象存储地址让你把 OceanBase 的全量备份和归档日志放进去。Minio 是开源的对象存储接口兼容 S3本地起一个就能模拟线上 OBS 环境。这也是很多选手第一次在这个环节翻车的地方备份目标配错、bucket 没建、时间不同步报错五花八门。# 下载 Minio Linux 二进制后授权从官网下载即可 chmod x minio # 启动 Minio/data 目录是对象存储的数据目录 MINIO_ROOT_USERobs_user MINIO_ROOT_PASSWORDobs_pass \ ./minio server /data --address :9000MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 是 Minio 的管理员凭证它们同时就是 S3 协议里的 AccessKey 和 SecretKey后面 OceanBase 备份配置里要使用同一对。--address 指定监听端口默认 9000比赛给的地址可能会换成别的端口注意对齐。然后创建备份用的 bucket# 用 Minio 客户端 mc 显式建桶 mc alias set minio http://127.0.0.1:9000 obs_user obs_pass mc mb minio/backupS3 协议要求 bucket 必须先存在不能像普通文件系统那样 mkdir -p 自动创建。建好桶之后回到 obclient 把备份目标指过去ALTER SYSTEM SET backup_dest oss://backup?host127.0.0.1port9000access_idobs_useraccess_keyobs_pass;这里用 oss:// 前缀是因为 OceanBase 内置的备份协议对对象存储统一走 OSS 兼容接口Minio 实现了 S3 API所以能直接对接。access_id 和 access_key 就是刚才 Minio 的那对凭证注意别漏了端口。执行成功后备份链路就通了。下面这个表列出部署阶段最常用的参数和端口方便你对照检查配置项示例值作用memory_limit8Gobserver 进程总内存上限system_memory1G系统租户预留内存datafile_size10G数据文件预分配大小log_disk_size10Gclog 等日志空间大小2881 / 2882端口SQL 连接 / RPC 通信backup_destoss://backup?…备份存储目标3. 核心功能实战租户隔离、并发控制和执行计划3.1 租户与资源单元建表题的前置动作OceanBase 的多租户架构是竞赛必考知识点。你在 sys 租户下建的业务表跟你在业务租户里建的表完全是两套数据空间。很多选手的题目是做出来了但建错了租户最后判题连不上血泪经验。创建租户前必须先准备资源单元和资源池CREATE RESOURCE UNIT u1 MAX_CPU 2, MEMORY_SIZE 4G; CREATE RESOURCE POOL p1 UNIT u1, UNIT_NUM 1; CREATE TENANT t1 RESOURCE_POOL_LIST (p1);MAX_CPU 是允许这个租户使用的 CPU 上限MEMORY_SIZE 是租户内存上限。UNIT_NUM 表示该资源池在集群内分布几个副本单元单机部署时只能设为 1设多了会因为单元分布失败而创建报错。这套概念对应生产环境的资源隔离租户之间内存、CPU 互相不抢占竞赛题里如果出现“某租户内存不足”或“超大查询拖垮其他租户”的场景都是在这里做手脚。租户建好后进入业务租户执行日常的建表和增删改查obclient -h127.0.0.1 -P2881 -uroott1 -proott1 是业务租户 t1 的超级管理员。首次进去先创建用户和授权因为比赛判题通常用一个独立账号连接CREATE USER study% IDENTIFIED BY study123; GRANT ALL PRIVILEGES ON *.* TO study%;这里 % 表示允许任意主机连接比赛判题环境经常从非本机 IP 连过来不加这个会连不上。然后在 study 用户下建表做增删改查语法在 MySQL 模式下几乎和 MySQL 一致差异主要在分区表、索引和事务细节上后面的小节会讲。3.2 并发控制快照读、当前读与死锁识别数据库并发锁是每次比赛都绕不开的题。OceanBase 的 MySQL 模式默认隔离级别是 repeatable-read在这个级别下普通 SELECT 是快照读不走加锁UPDATE、DELETE 和 SELECT ... FOR UPDATE 是当前读要拿行锁。这个区别是很多并发题的核心。我一般会在本地起两个会话验证行锁行为-- 会话 A CREATE TABLE t_lock(id INT PRIMARY KEY, val INT); INSERT INTO t_lock VALUES(1,10),(2,20); -- 会话 A 开启事务并更新 BEGIN; UPDATE t_lock SET val 100 WHERE id 1; -- 会话 B 更新同一行会阻塞直到 A 提交或回滚 UPDATE t_lock SET val 200 WHERE id 1;会话 B 的 UPDATE 会卡住说明 id1 这行的行锁被会话 A 持有。再验证快照读不加锁-- 会话 B 此时执行普通 SELECT不走锁直接读到提交前的旧快照 SELECT * FROM t_lock WHERE id 1;如果 B 的 SELECT 能立刻返回 10 而不是阻塞就说明这是快照读。如果 B 用 SELECT ... FOR UPDATE就会像 UPDATE 一样排队等锁。这一组差异在比赛里经常被拿来出“分析事务隔离级别”的题。死锁则是两个事务互相等对方持有的锁。比如 A 锁了 id1 再要 id2B 锁了 id2 再要 id1OceanBase 会检测到死锁并让其中一个事务回滚报错信息里通常带着 deadlock 关键字。识别死锁的办法是看错误码和时间戳如果一条 UPDATE 等了很久才报错多半不是偶发阻塞而是死锁。竞赛里遇到这类题优先检查是否存在交叉加锁的顺序把两个事务的加锁顺序统一就能避免。3.3 用 EXPLAIN 判断索引是否真正生效执行计划分析是调优题的主要拿分点。很多选手以为建了索引就万事大吉结果 EXPLAIN 出来还是全表扫描这就是索引没生效。常见原因有三种查询条件没走索引最左前缀、隐式类型转换导致索引失效、统计信息过期让优化器选了全表扫。先看一个最简单的场景CREATE TABLE t_idx(id INT PRIMARY KEY, val INT, note VARCHAR(50)); INSERT INTO t_idx SELECT LEVEL, LEVEL * 10, x FROM DUAL CONNECT BY LEVEL 10000; -- 没索引时val 上的过滤会走全表扫描 EXPLAIN SELECT * FROM t_idx WHERE val 20;没有索引时执行计划里会出现 TABLE SCAN 或 TABLE FULL SCAN。然后建索引再看CREATE INDEX idx_val ON t_idx(val); EXPLAIN SELECT * FROM t_idx WHERE val 20;建完索引后计划会变成 INDEX RANGE SCAN这意味着优化器通过索引定位到目标行回表次数大幅减少。注意 EXPLAIN 输出里 plan_type 和 operator 行是关键operator 里写着 TABLE SCAN 还是 INDEX SCAN 一眼就能判断。再看一个容易被忽略的覆盖索引。如果查询只要返回 id 和 val而索引已经包含这两个字段就不需要回表CREATE INDEX idx_val_cover ON t_idx(val, id); EXPLAIN SELECT id, val FROM t_idx WHERE val 20;执行计划里出现 INDEX FULL SCAN 且没有回表算子就是覆盖索引生效。这里隐含了一个调优思路不要无条件给所有列建单独索引优先把高频过滤列和查询列组合成联合索引回表次数降下来性能提升比单纯加内存还明显。下面这个表是判断执行计划时的快速参考执行计划特征含义出现原因TABLE SCAN全表扫描无条件主键可走但没走或统计信息过旧INDEX RANGE SCAN索引范围扫描索引生效过滤条件命中索引区间INDEX FULL SCAN覆盖索引扫描查询列都在索引内无需回表NESTED LOOP JOIN嵌套循环连接小表驱动大表连接列有索引时常见4. 避坑排查五个让选手翻车的典型问题4.1 连接与驱动识别问题现象obclient 连接 OceanBase 时直接报 “couldnt deduct database type from database product name oceanbase”或者 JDBC 方式连接后程序死活拿不到连接。原因这个报错本质是客户端或驱动在解析元数据时拿数据库返回的 product name 去匹配类型而 OceanBase 返回的是 oceanbase 而不是 mysql一些按 MySQL 硬编码识别的旧驱动就不认账。解决竞赛环境一律用官方 obclientJDBC 则用官方驱动连接串写成 jdbc:oceanbase://127.0.0.1:2881/ 而不是 jdbc:mysql://。另外注意 OceanBase 的连接地址里要带租户信息URL 里没有租户名时驱动不知道去哪个租户鉴权。第二条现象用 Navicat 或 DBeaver 之类 GUI 工具连接时报“数据库类型不支持”或能连上但看不到业务租户。原因图形工具对 OceanBase 的兼容分版本有些工具识别的是兼容模式默认只看到 sys 租户业务租户被当成普通 schema 显示。解决先用 obclient 确认业务租户和用户都建好再用 GUI 工具连接时在连接参数里显式指定租户名不要依赖默认值。4.2 资源与进程问题现象obd cluster start 执行后 observer 进程反复拉起又退出日志里出现端口 bind 失败或者直接报 memory 相关错误。原因端口被占用或者 memory_limit 给得太大超过了机器实际可用内存。observer 启动时会根据 memory_limit 预分配内存段给 16G 但机器只有 8G内核就会拒绝分配。解决先用ss -lntp | grep 2881和free -g分别确认端口和内存。端口被占就杀掉旧进程或改端口配置内存不足就把 memory_limit 压到机器物理内存的一半以下system_memory 也同步调小。改完参数后重新执行obd cluster restart ob_test。第三条现象集群能起来但跑了一段后写入变慢日志里出现 clog 目录写满或日志盘告警。原因log_disk_size 设置太小事务日志写满后集群进入只读保护状态所有 DML 都会被阻塞。解决log_disk_size 至少给到 datafile_size 的 1/3如果磁盘空间允许直接按 20G 给。检查当前日志盘使用率可以用SHOW PARAMETERS LIKE log_disk_size和系统租户下的视图确认不要等到报只读才想起来。4.3 备份与时间同步问题现象执行 ALTER SYSTEM BACKUP DATABASE 后备份任务很快失败Minio 端日志里出现 SignatureDoesNotMatch 或 RequestTimeTooSkewed。原因S3 签名校验要求客户端与服务器的系统时间差在 15 分钟以内OceanBase 所在机器和 Minio 所在机器如果时间不同步签名自然对不上。这是对象存储备份最典型的坑和用户密码对错无关。解决在两台机器上都执行一次时间同步例如sudo ntpdate ntp.aliyun.com或使用 timedatectl 启用 NTP 服务然后等一两分钟重新发起备份。另外确认 backup_dest 里 access_key 和 access_password 与 Minio 启动时的 MINIO_ROOT_USER、MINIO_ROOT_PASSWORD 完全一致一个字符都不能差。5. 进阶验证从备份恢复到压测把调优结论固化成命令资源准备到这个阶段环境能跑、SQL 能写、坑也知道在哪接下来最重要的事情是把调优效果验证到具体数字上而不是凭感觉说“快了”。比赛里判题不看优化器日志只看最终执行时间和吞吐所以你要有一套可复现的压测命令。sysbench 是 OceanBase 官方支持的压力工具obd 直接封装了调用方式obd test sysbench ob_test --tenant t1 --password study123 \ --tables 10 --table-size 10000 --threads 8 --time 120--tenant 指定业务租户名--password 对应该租户下用户密码--tables 和 --table-size 控制压测数据规模我一般先给 10 张表、每表一万行跑 120 秒观察 QPS 和延迟曲线。压测结束后输出里的 latency 和 tps 是核心指标先记录基线再调参再压测调优才叫闭环。参数调整集中在内存和并发线程。最常用的是这两个ALTER SYSTEM SET memory_limit 12G; ALTER SYSTEM SET log_disk_size 20G;memory_limit 扩大后block cache 和 memtable 有更多空间读多写少的场景提升明显log_disk_size 扩大后日志写压力降低高并发写入时不容易触发保护机制。注意改 memory_limit 前确认机器物理内存充足改完后重启 observer 才会稳定生效而 log_disk_size 多数场景可以动态调整不用重启。备份恢复验证是最后一关。调优再好备份失败或恢复不出来比赛里一样零分。我固定用下面这串命令确认备份链路-- 开启归档模式 ALTER SYSTEM ARCHIVELOG; -- 发起全量备份 ALTER SYSTEM BACKUP DATABASE; -- 确认备份任务状态STATUS 为 SUCCESS 才算完成 SELECT JOB_ID, TENANT_ID, STATUS, START_TIME, END_TIME FROM DBA_OB_BACKUP_JOBS ORDER BY JOB_ID DESC LIMIT 5;STATUS 字段是关键看到 SUCCESS 再往下走。如果一直停在 RUNNING去对应备份目录检查文件是否在增长大概率是磁盘容量或网络问题而不是 SQL 本身的问题。这套流程里我最想强调的习惯是每改一个参数就重新压测一轮并记录改动前后的 tps 和延迟而不是一次性堆五个参数上去。比赛环境变量太多一次性全改翻车了都不知道是哪一行配置引起的。从那以后我每次配完比赛环境都会强制走一遍“部署→建租户→压测基线→备份→确认任务→恢复演练”的完整链路确认每一步都有输出记录然后才碰优化参数。这个习惯救过我一次比赛前一晚我误删了一个租户依赖备份目录里的全量文件和归档日志愣是用这套流程在两个小时内把数据恢复了回来。希望帮到你。本文还有配套的精品资源点击获取 OceanBase大赛备赛：从obd部署到备份调优的完整实战指南
简介一份面向2025年全国大学生计算机系统能力大赛第五届OceanBase数据库大赛的完整项目资料包适合参赛学生、数据库爱好者以及希望深入分布式数据库内核的开发者参考。资源共包含2000个文件主要类型为C/C源文件与头文件、Markdown说明文档、JSON配置文件、Python辅助脚本及测试样例同时包含构建脚本、Git版本控制对象、预期输出及配置模板代码与文档比例均衡整体约113.94MB。该资料包已有50人学习下载。内容覆盖比赛所需的基础代码、文档说明、测试用例与工具脚本可以帮助参赛队伍快速理解OceanBase核心实现、掌握竞赛考点也可作为高校数据库课程设计和系统能力训练的有力素材对于研究数据库存储引擎、事务处理等模块的开发者同样具有参考价值。1. OceanBase 备赛资源拆解先解决“集群起不来”再谈调优很多第一次碰 OceanBase 的同学不是被 SQL 题难倒而是卡在最前面集群起不来、租户建不出来、写个备份脚本连上对象存储又被签名错误打回。这个竞赛表面考 SQL 和调优实际先考你能不能把一套分布式数据库拉到能跑的状态。我拆这份第五届 OceanBase 数据库大赛备赛资源时最大的感受是它没有按官方文档顺序堆知识而是按一条比赛真实路径排下来——从 obd 部署、租户资源隔离到 Minio 对象存储备份、执行计划调优全部落在具体命令和参数上连翻车现场都给了对照解法。适合两类人一类是准备参赛、想省下大量调研时间的学生另一类是想快速上手 OceanBase、拿竞赛题当场景练手的从业者。这篇笔记会把环境部署、核心功能、避坑记录和调优验证依次过一遍你在本地机器上照着走就能复现。2. 环境搭建用 obd 拉起 OceanBase把备份落到 Minio2.1 为什么竞赛环境首选 obd 单机部署OceanBase 是分布式架构生产环境至少三台机器起步但竞赛场景绝大多数题目不要求跨机分布式能力反而更看重你能否快速起一个可用集群。常见做法是用 obdOceanBase Deployer在一台主机上部署一个 observer 实例CPU、内存、日志盘都按本机配置收缩。obd 的价值在于把配置生成、进程拉起、状态检查都封装成命令你不用手工去写 systemd 脚本也不用担心 observer 进程以什么用户启动、数据目录建在哪这种琐碎问题。另一个选择是直接下载 RPM 包手动部署但我一般不建议在竞赛准备阶段这么做。手动部署需要自己管理 observer 进程、初始化系统租户、处理目录权限任何一个环节出错都会浪费半天。用 obd 的好处是你少踩一半环境坑把精力留给后面真正拉分的 SQL 和调优题。需要提醒的是obd 只是部署工具不等于 OceanBase 本身后续所有 SQL 操作还是在 obclient 里完成。2.2 部署命令与关键参数先装 obd。这里的 ob-deployer 是管理端工具装好后用这里写好的最小配置拉一个单机实例# 安装 obd不同发行版用对应包管理器这里以 CentOS 系的 yum 为例 sudo yum install -y ob-deployer # 用 here-doc 生成最小集群配置单机跑一个 observer cat obtest.yaml EOF oceanbase-ce: servers: - 127.0.0.1 global: home_path: /home/admin/oceanbase memory_limit: 8G system_memory: 1G datafile_size: 10G log_disk_size: 10G EOF # 根据配置自动生成集群并启动 obd cluster autodeploy ob_test -c obtest.yaml obd cluster start ob_testautodeploy 会读取 obtest.yaml 里的参数生成完整的 observer 配置并拉起进程。memory_limit 控制 observer 进程可使用的总内存8G 是比赛常见配置如果你的机器只有 8G 内存把这个值压到 4G同时把 system_memory 降到 1G 以下。datafile_size 是数据文件预分配大小10G 在本地磁盘够用log_disk_size 是日志盘空间太小会导致 clog 写满后集群停止写入这个参数宁可给大一点。启动完成后验证一下 observer 状态obclient -h127.0.0.1 -P2881 -urootsys -p默认端口 2881 是 SQL 连接端口2882 是 RPC 端口。rootsys 是系统租户的管理员账号首次登录密码在 obd 部署时如果没有显式指定通常为空或按部署输出提示设置。登录后执行一句确认SELECT * FROM DBA_OB_SERVERS\G能看到 observer 的 status、start_service_time 等字段status 为 ACTIVE 说明集群已经可用了。这一步通过后再继续建租户顺序别反很多同学一上来就建表结果连接的是 sys 租户后面所有业务租户的题全白做。2.3 把 Minio 接进备份链路比赛里经常给一个 Minio 或兼容 S3 的对象存储地址让你把 OceanBase 的全量备份和归档日志放进去。Minio 是开源的对象存储接口兼容 S3本地起一个就能模拟线上 OBS 环境。这也是很多选手第一次在这个环节翻车的地方备份目标配错、bucket 没建、时间不同步报错五花八门。# 下载 Minio Linux 二进制后授权从官网下载即可 chmod x minio # 启动 Minio/data 目录是对象存储的数据目录 MINIO_ROOT_USERobs_user MINIO_ROOT_PASSWORDobs_pass \ ./minio server /data --address :9000MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 是 Minio 的管理员凭证它们同时就是 S3 协议里的 AccessKey 和 SecretKey后面 OceanBase 备份配置里要使用同一对。--address 指定监听端口默认 9000比赛给的地址可能会换成别的端口注意对齐。然后创建备份用的 bucket# 用 Minio 客户端 mc 显式建桶 mc alias set minio http://127.0.0.1:9000 obs_user obs_pass mc mb minio/backupS3 协议要求 bucket 必须先存在不能像普通文件系统那样 mkdir -p 自动创建。建好桶之后回到 obclient 把备份目标指过去ALTER SYSTEM SET backup_dest oss://backup?host127.0.0.1port9000access_idobs_useraccess_keyobs_pass;这里用 oss:// 前缀是因为 OceanBase 内置的备份协议对对象存储统一走 OSS 兼容接口Minio 实现了 S3 API所以能直接对接。access_id 和 access_key 就是刚才 Minio 的那对凭证注意别漏了端口。执行成功后备份链路就通了。下面这个表列出部署阶段最常用的参数和端口方便你对照检查配置项示例值作用memory_limit8Gobserver 进程总内存上限system_memory1G系统租户预留内存datafile_size10G数据文件预分配大小log_disk_size10Gclog 等日志空间大小2881 / 2882端口SQL 连接 / RPC 通信backup_destoss://backup?…备份存储目标3. 核心功能实战租户隔离、并发控制和执行计划3.1 租户与资源单元建表题的前置动作OceanBase 的多租户架构是竞赛必考知识点。你在 sys 租户下建的业务表跟你在业务租户里建的表完全是两套数据空间。很多选手的题目是做出来了但建错了租户最后判题连不上血泪经验。创建租户前必须先准备资源单元和资源池CREATE RESOURCE UNIT u1 MAX_CPU 2, MEMORY_SIZE 4G; CREATE RESOURCE POOL p1 UNIT u1, UNIT_NUM 1; CREATE TENANT t1 RESOURCE_POOL_LIST (p1);MAX_CPU 是允许这个租户使用的 CPU 上限MEMORY_SIZE 是租户内存上限。UNIT_NUM 表示该资源池在集群内分布几个副本单元单机部署时只能设为 1设多了会因为单元分布失败而创建报错。这套概念对应生产环境的资源隔离租户之间内存、CPU 互相不抢占竞赛题里如果出现“某租户内存不足”或“超大查询拖垮其他租户”的场景都是在这里做手脚。租户建好后进入业务租户执行日常的建表和增删改查obclient -h127.0.0.1 -P2881 -uroott1 -proott1 是业务租户 t1 的超级管理员。首次进去先创建用户和授权因为比赛判题通常用一个独立账号连接CREATE USER study% IDENTIFIED BY study123; GRANT ALL PRIVILEGES ON *.* TO study%;这里 % 表示允许任意主机连接比赛判题环境经常从非本机 IP 连过来不加这个会连不上。然后在 study 用户下建表做增删改查语法在 MySQL 模式下几乎和 MySQL 一致差异主要在分区表、索引和事务细节上后面的小节会讲。3.2 并发控制快照读、当前读与死锁识别数据库并发锁是每次比赛都绕不开的题。OceanBase 的 MySQL 模式默认隔离级别是 repeatable-read在这个级别下普通 SELECT 是快照读不走加锁UPDATE、DELETE 和 SELECT ... FOR UPDATE 是当前读要拿行锁。这个区别是很多并发题的核心。我一般会在本地起两个会话验证行锁行为-- 会话 A CREATE TABLE t_lock(id INT PRIMARY KEY, val INT); INSERT INTO t_lock VALUES(1,10),(2,20); -- 会话 A 开启事务并更新 BEGIN; UPDATE t_lock SET val 100 WHERE id 1; -- 会话 B 更新同一行会阻塞直到 A 提交或回滚 UPDATE t_lock SET val 200 WHERE id 1;会话 B 的 UPDATE 会卡住说明 id1 这行的行锁被会话 A 持有。再验证快照读不加锁-- 会话 B 此时执行普通 SELECT不走锁直接读到提交前的旧快照 SELECT * FROM t_lock WHERE id 1;如果 B 的 SELECT 能立刻返回 10 而不是阻塞就说明这是快照读。如果 B 用 SELECT ... FOR UPDATE就会像 UPDATE 一样排队等锁。这一组差异在比赛里经常被拿来出“分析事务隔离级别”的题。死锁则是两个事务互相等对方持有的锁。比如 A 锁了 id1 再要 id2B 锁了 id2 再要 id1OceanBase 会检测到死锁并让其中一个事务回滚报错信息里通常带着 deadlock 关键字。识别死锁的办法是看错误码和时间戳如果一条 UPDATE 等了很久才报错多半不是偶发阻塞而是死锁。竞赛里遇到这类题优先检查是否存在交叉加锁的顺序把两个事务的加锁顺序统一就能避免。3.3 用 EXPLAIN 判断索引是否真正生效执行计划分析是调优题的主要拿分点。很多选手以为建了索引就万事大吉结果 EXPLAIN 出来还是全表扫描这就是索引没生效。常见原因有三种查询条件没走索引最左前缀、隐式类型转换导致索引失效、统计信息过期让优化器选了全表扫。先看一个最简单的场景CREATE TABLE t_idx(id INT PRIMARY KEY, val INT, note VARCHAR(50)); INSERT INTO t_idx SELECT LEVEL, LEVEL * 10, x FROM DUAL CONNECT BY LEVEL 10000; -- 没索引时val 上的过滤会走全表扫描 EXPLAIN SELECT * FROM t_idx WHERE val 20;没有索引时执行计划里会出现 TABLE SCAN 或 TABLE FULL SCAN。然后建索引再看CREATE INDEX idx_val ON t_idx(val); EXPLAIN SELECT * FROM t_idx WHERE val 20;建完索引后计划会变成 INDEX RANGE SCAN这意味着优化器通过索引定位到目标行回表次数大幅减少。注意 EXPLAIN 输出里 plan_type 和 operator 行是关键operator 里写着 TABLE SCAN 还是 INDEX SCAN 一眼就能判断。再看一个容易被忽略的覆盖索引。如果查询只要返回 id 和 val而索引已经包含这两个字段就不需要回表CREATE INDEX idx_val_cover ON t_idx(val, id); EXPLAIN SELECT id, val FROM t_idx WHERE val 20;执行计划里出现 INDEX FULL SCAN 且没有回表算子就是覆盖索引生效。这里隐含了一个调优思路不要无条件给所有列建单独索引优先把高频过滤列和查询列组合成联合索引回表次数降下来性能提升比单纯加内存还明显。下面这个表是判断执行计划时的快速参考执行计划特征含义出现原因TABLE SCAN全表扫描无条件主键可走但没走或统计信息过旧INDEX RANGE SCAN索引范围扫描索引生效过滤条件命中索引区间INDEX FULL SCAN覆盖索引扫描查询列都在索引内无需回表NESTED LOOP JOIN嵌套循环连接小表驱动大表连接列有索引时常见4. 避坑排查五个让选手翻车的典型问题4.1 连接与驱动识别问题现象obclient 连接 OceanBase 时直接报 “couldnt deduct database type from database product name oceanbase”或者 JDBC 方式连接后程序死活拿不到连接。原因这个报错本质是客户端或驱动在解析元数据时拿数据库返回的 product name 去匹配类型而 OceanBase 返回的是 oceanbase 而不是 mysql一些按 MySQL 硬编码识别的旧驱动就不认账。解决竞赛环境一律用官方 obclientJDBC 则用官方驱动连接串写成 jdbc:oceanbase://127.0.0.1:2881/ 而不是 jdbc:mysql://。另外注意 OceanBase 的连接地址里要带租户信息URL 里没有租户名时驱动不知道去哪个租户鉴权。第二条现象用 Navicat 或 DBeaver 之类 GUI 工具连接时报“数据库类型不支持”或能连上但看不到业务租户。原因图形工具对 OceanBase 的兼容分版本有些工具识别的是兼容模式默认只看到 sys 租户业务租户被当成普通 schema 显示。解决先用 obclient 确认业务租户和用户都建好再用 GUI 工具连接时在连接参数里显式指定租户名不要依赖默认值。4.2 资源与进程问题现象obd cluster start 执行后 observer 进程反复拉起又退出日志里出现端口 bind 失败或者直接报 memory 相关错误。原因端口被占用或者 memory_limit 给得太大超过了机器实际可用内存。observer 启动时会根据 memory_limit 预分配内存段给 16G 但机器只有 8G内核就会拒绝分配。解决先用ss -lntp | grep 2881和free -g分别确认端口和内存。端口被占就杀掉旧进程或改端口配置内存不足就把 memory_limit 压到机器物理内存的一半以下system_memory 也同步调小。改完参数后重新执行obd cluster restart ob_test。第三条现象集群能起来但跑了一段后写入变慢日志里出现 clog 目录写满或日志盘告警。原因log_disk_size 设置太小事务日志写满后集群进入只读保护状态所有 DML 都会被阻塞。解决log_disk_size 至少给到 datafile_size 的 1/3如果磁盘空间允许直接按 20G 给。检查当前日志盘使用率可以用SHOW PARAMETERS LIKE log_disk_size和系统租户下的视图确认不要等到报只读才想起来。4.3 备份与时间同步问题现象执行 ALTER SYSTEM BACKUP DATABASE 后备份任务很快失败Minio 端日志里出现 SignatureDoesNotMatch 或 RequestTimeTooSkewed。原因S3 签名校验要求客户端与服务器的系统时间差在 15 分钟以内OceanBase 所在机器和 Minio 所在机器如果时间不同步签名自然对不上。这是对象存储备份最典型的坑和用户密码对错无关。解决在两台机器上都执行一次时间同步例如sudo ntpdate ntp.aliyun.com或使用 timedatectl 启用 NTP 服务然后等一两分钟重新发起备份。另外确认 backup_dest 里 access_key 和 access_password 与 Minio 启动时的 MINIO_ROOT_USER、MINIO_ROOT_PASSWORD 完全一致一个字符都不能差。5. 进阶验证从备份恢复到压测把调优结论固化成命令资源准备到这个阶段环境能跑、SQL 能写、坑也知道在哪接下来最重要的事情是把调优效果验证到具体数字上而不是凭感觉说“快了”。比赛里判题不看优化器日志只看最终执行时间和吞吐所以你要有一套可复现的压测命令。sysbench 是 OceanBase 官方支持的压力工具obd 直接封装了调用方式obd test sysbench ob_test --tenant t1 --password study123 \ --tables 10 --table-size 10000 --threads 8 --time 120--tenant 指定业务租户名--password 对应该租户下用户密码--tables 和 --table-size 控制压测数据规模我一般先给 10 张表、每表一万行跑 120 秒观察 QPS 和延迟曲线。压测结束后输出里的 latency 和 tps 是核心指标先记录基线再调参再压测调优才叫闭环。参数调整集中在内存和并发线程。最常用的是这两个ALTER SYSTEM SET memory_limit 12G; ALTER SYSTEM SET log_disk_size 20G;memory_limit 扩大后block cache 和 memtable 有更多空间读多写少的场景提升明显log_disk_size 扩大后日志写压力降低高并发写入时不容易触发保护机制。注意改 memory_limit 前确认机器物理内存充足改完后重启 observer 才会稳定生效而 log_disk_size 多数场景可以动态调整不用重启。备份恢复验证是最后一关。调优再好备份失败或恢复不出来比赛里一样零分。我固定用下面这串命令确认备份链路-- 开启归档模式 ALTER SYSTEM ARCHIVELOG; -- 发起全量备份 ALTER SYSTEM BACKUP DATABASE; -- 确认备份任务状态STATUS 为 SUCCESS 才算完成 SELECT JOB_ID, TENANT_ID, STATUS, START_TIME, END_TIME FROM DBA_OB_BACKUP_JOBS ORDER BY JOB_ID DESC LIMIT 5;STATUS 字段是关键看到 SUCCESS 再往下走。如果一直停在 RUNNING去对应备份目录检查文件是否在增长大概率是磁盘容量或网络问题而不是 SQL 本身的问题。这套流程里我最想强调的习惯是每改一个参数就重新压测一轮并记录改动前后的 tps 和延迟而不是一次性堆五个参数上去。比赛环境变量太多一次性全改翻车了都不知道是哪一行配置引起的。从那以后我每次配完比赛环境都会强制走一遍“部署→建租户→压测基线→备份→确认任务→恢复演练”的完整链路确认每一步都有输出记录然后才碰优化参数。这个习惯救过我一次比赛前一晚我误删了一个租户依赖备份目录里的全量文件和归档日志愣是用这套流程在两个小时内把数据恢复了回来。希望帮到你。本文还有配套的精品资源点击获取