一、为什么OceanBase性能优化需要全链路视角
很多企业上了OceanBase之后，感觉"应该比MySQL快"，但实际跑起来却发现某些核心交易场景的性能并不理想，甚至不如原来的单机数据库。这其实是一个很常见的现象，原因就在于性能优化不是某一个环节的事，而是一条从SQL编写到存储引擎的完整链路。
OceanBase是一个分布式关系型数据库，它的架构和传统的单机MySQL有很大的区别。它把数据分散存储在不同的节点上，通过多副本机制保证数据可靠性。这种架构带来的好处是高可用和高扩展，但也意味着性能优化需要考虑的因素更多——不仅仅是SQL怎么写的问题，还包括数据在存储层怎么放、怎么读、怎么写入。
打个比方，如果你把OceanBase比作一条高速公路，那SQL调优就像是优化你的驾驶技术，存储层配置就像是修路和扩宽车道。你开车技术再好，路太窄照样跑不快；路再宽，如果你开车技术差，也发挥不出路的潜力。所以性能优化必须是全链路的，从最上层的SQL一直到最底层的存储配置，每个环节都要考虑到。
这篇文章就从实际应用出发，手把手教你如何在OceanBase的核心交易场景中做全链路性能优化。
1.1 全链路优化的三个层次
在OceanBase中，性能优化可以分为三个层次：
第一层：SQL层优化 —— 这是最直观的优化手段。一条写得不好的SQL，可能让数据库扫描上百万行数据，而优化后可能只需要扫描几千行。这一层优化的性价比最高，因为它不需要修改数据库配置，只需要改代码。
第二层：索引与执行计划优化 —— 有时候SQL本身没问题，但数据库的执行计划走了一个非常低效的路径。这时候就需要通过分析执行计划，调整索引设计或者使用优化器提示来引导数据库走正确的路径。
第三层：存储层配置优化 —— 这是最底层也最容易被忽视的优化。OceanBase的存储层有很多参数配置，比如内存分配、日志刷盘策略、合并策略等，这些参数直接影响数据库的吞吐量和延迟。
1.2 本文适用场景
本文主要针对以下核心交易场景的性能优化：
- 电商下单场景：高并发写入，需要毫秒级响应
- 金融交易场景：强一致性要求，事务密集
- 订单查询场景：复杂条件查询，数据量在千万级别
- 库存扣减场景：热点行更新，高并发争用
二、SQL层面的性能调优
2.1 避免全表扫描是第一步
全表扫描是OceanBase中最常见的性能杀手。当一条SQL没有合适的索引时，数据库就必须逐行扫描整张表来找到目标数据。在数据量大的表上，这个操作的代价非常高。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：对比全表扫描和索引扫描的性能差异
-- ============================================================
-- 创建测试表，模拟订单数据
CREATE TABLE IF NOT EXISTS t_order (
order_id BIGINT NOT NULL PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
shop_id BIGINT NOT NULL,
order_status TINYINT NOT NULL DEFAULT 0,
total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00,
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ORGANIZATION INDEX;
-- 说明：ORGANIZATION INDEX表示表数据按照主键索引组织存储
-- 插入模拟数据（实际测试中可以用批量插入）
-- 模拟100万条订单记录
INSERT INTO t_order (user_id, shop_id, order_status, total_amount, create_time)
SELECT
FLOOR(RAND() * 10000), -- 随机用户ID（1万用户）
FLOOR(RAND() * 500), -- 随机店铺ID（500店铺）
FLOOR(RAND() * 5), -- 随机订单状态（0-4）
ROUND(RAND() * 10000, 2), -- 随机金额
NOW() - INTERVAL FLOOR(RAND() * 365) DAY -- 最近一年的订单
FROM (
-- 使用序列生成器来构造多行数据
SELECT 1 AS num UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) a,
(
SELECT 1 AS num UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) b,
(
SELECT 1 AS num UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) c,
(
SELECT 1 AS num UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) d,
(
SELECT 1 AS num UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) e;
来看看一条典型的全表扫描SQL：
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：全表扫描的典型写法 —— 尽量避免
-- ============================================================
-- 问题SQL：WHERE条件中的字段没有被索引覆盖
-- 用户查询自己最近一个月的未完成订单
EXPLAIN SELECT
order_id,
shop_id,
total_amount,
create_time
FROM t_order
WHERE user_id = 12345 -- 如果没有索引，这里会触发全表扫描
AND order_status IN (0, 1, 2) -- 状态过滤
AND create_time > NOW() - INTERVAL 30 DAY -- 时间范围
ORDER BY create_time DESC
LIMIT 20;
-- 说明：如果user_id上没有索引，OceanBase需要扫描整张表的每一行，
-- 然后逐行判断条件是否满足。数据量越大，这个操作越慢。
正确的做法是为高频查询字段建立合适的索引：
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：通过建立复合索引消除全表扫描
-- ============================================================
-- 为user_id + order_status + create_time建立复合索引
-- 这个索引的顺序很重要：最左前缀原则
-- 先按user_id过滤，再按order_status过滤，最后按create_time排序和过滤
CREATE INDEX idx_user_status_time
ON t_order(user_id, order_status, create_time);
-- 说明：
-- 1. user_id放在最前面：因为几乎所有查询都会带这个条件
-- 2. order_status放在中间：状态值只有5种，选择性不高，但配合user_id可以进一步缩小范围
-- 3. create_time放在最后：既用于范围过滤，也用于ORDER BY排序，可以避免额外的排序步骤
-- 验证优化效果
EXPLAIN SELECT
order_id,
shop_id,
total_amount,
create_time
FROM t_order
WHERE user_id = 12345
AND order_status IN (0, 1, 2)
AND create_time > NOW() - INTERVAL 30 DAY
ORDER BY create_time DESC
LIMIT 20;
-- 预期效果：执行计划中应该显示Index Range Scan（索引范围扫描），
-- 而不是Table Full Scan（全表扫描），扫描行数应该大幅减少。
2.2 理解OceanBase的执行计划
OceanBase的执行计划是理解SQL性能的关键。通过EXPLAIN命令，我们可以看到数据库打算怎么执行一条SQL。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：详细分析执行计划的各个字段含义
-- ============================================================
-- 使用EXPLAIN查看执行计划
EXPLAIN SELECT
o.order_id,
o.total_amount,
p.product_name,
p.price
FROM t_order o
INNER JOIN t_order_item oi ON o.order_id = oi.order_id
INNER JOIN t_product p ON oi.product_id = p.product_id
WHERE o.user_id = 12345
AND o.order_status = 1;
-- 说明：执行计划中需要重点关注以下字段：
-- 1. operator（算子）：表示这一步做什么操作
-- - TABLE SCAN：全表扫描，通常需要优化
-- - INDEX RANGE SCAN：索引范围扫描，比较高效
-- - INDEX FULL SCAN：索引全扫描，比全表扫描好一点
-- - HASH JOIN / NESTED LOOP JOIN：连接操作
-- 2. rows（行数估计）：这一步预计返回多少行
-- 如果这个数字很大，说明这一步的代价很高
-- 3. cost（代价估计）：优化器对这个执行路径的代价评估
-- 4. filter（过滤条件）：这一步的WHERE条件
-- 查看更详细的执行计划（包括实际运行时的信息）
-- 使用EXPLAIN EXTENDED可以更详细地看到优化器的决策过程
EXPLAIN EXTENDED SELECT
o.order_id,
o.total_amount,
p.product_name,
p.price
FROM t_order o
INNER JOIN t_order_item oi ON o.order_id = oi.order_id
INNER JOIN t_product p ON oi.product_id = p.product_id
WHERE o.user_id = 12345
AND o.order_status = 1;
2.3 减少网络开销：避免不必要的回表
在OceanBase中，如果只查询索引列的数据，就不需要回表去查数据行本身。回表意味着数据库需要额外读取数据页，这会增加IO开销。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：通过覆盖索引避免回表
-- ============================================================
-- 场景：查询用户的所有已完成订单ID和金额
-- 如果只查order_id和total_amount，可以创建覆盖索引
-- 创建一个覆盖索引，包含所有需要查询的字段
CREATE INDEX idx_user_covering
ON t_order(user_id, order_status, order_id, total_amount);
-- 说明：
-- 这个索引包含了user_id、order_status、order_id、total_amount四个字段
-- 当查询只需要这些字段时，OceanBase可以直接从索引中获取数据，
-- 不需要回表去查数据页，这就是"覆盖索引"。
-- 使用覆盖索引的查询（不需要回表）
EXPLAIN SELECT
order_id,
total_amount
FROM t_order
WHERE user_id = 12345
AND order_status = 3;
-- 预期效果：执行计划中应该显示"Covering Index Scan"或类似信息
-- 对比：如果查询的字段不在索引中，就需要回表
-- 下面的查询需要回表，因为shop_id不在覆盖索引中
EXPLAIN SELECT
order_id,
total_amount,
shop_id -- 这个字段不在索引中，需要回表
FROM t_order
WHERE user_id = 12345
AND order_status = 3;
2.4 批量操作优化
在交易场景中，很多时候需要批量插入或更新数据。在OceanBase中，合理的批量操作策略可以显著提升性能。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：批量插入的优化写法
-- ============================================================
-- 不好的做法：逐条插入（网络开销大，事务开销大）
-- 每插入一条就要一次网络往返，非常低效
-- INSERT INTO t_order (user_id, shop_id, order_status, total_amount) VALUES (1, 2, 0, 100.00);
-- INSERT INTO t_order (user_id, shop_id, order_status, total_amount) VALUES (1, 3, 0, 200.00);
-- INSERT INTO t_order (user_id, shop_id, order_status, total_amount) VALUES (1, 4, 0, 300.00);
-- 说明：这种方式每次INSERT都是一个独立的事务，开销非常大
-- 好的做法：使用批量插入（一次网络往返，一个事务）
INSERT INTO t_order (user_id, shop_id, order_status, total_amount) VALUES
(1, 2, 0, 100.00),
(1, 3, 0, 200.00),
(1, 4, 0, 300.00),
(1, 5, 0, 400.00),
(1, 6, 0, 500.00);
-- 说明：批量插入可以在一次SQL中插入多条记录，
-- 减少网络往返次数和事务提交次数，性能提升非常明显
-- 对于大批量数据导入，建议使用LOAD DATA语句
-- LOAD DATA可以比INSERT快10倍以上
LOAD DATA LOCAL INFILE '/data/orders.csv'
INTO TABLE t_order
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
IGNORE 1 ROWS -- 跳过第一行（表头）
(user_id, shop_id, order_status, total_amount);
-- 说明：
-- LOAD DATA直接从文件加载数据，绕过了SQL解析和优化的开销
-- 适合数据迁移、批量导入等场景
2.5 使用优化器提示（Hint）引导执行计划
有时候OceanBase的优化器选择了一个并不理想的执行计划，这时候可以使用Hint来引导优化器走正确的路径。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：使用优化器提示（Hint）干预执行计划
-- ============================================================
-- 场景：两个大表JOIN时，优化器选择了错误的JOIN顺序
-- 优化器认为表A大表B小，但实际上当前数据分布下应该是表B小表A大
-- 查看优化器选择的执行计划
EXPLAIN SELECT
o.order_id,
d.delivery_address,
d.receiver_name
FROM t_order o
INNER JOIN t_delivery d ON o.order_id = d.order_id
WHERE o.user_id = 12345
AND o.create_time > NOW() - INTERVAL 30 DAY;
-- 如果执行计划显示先扫描t_delivery全表再做JOIN，那就不是最优的
-- 使用Hint指定以t_order为驱动表
SELECT /*+ LEADING(o d) USE_INDEX(o idx_user_status_time) */
o.order_id,
d.delivery_address,
d.receiver_name
FROM t_order o
INNER JOIN t_delivery d ON o.order_id = d.order_id
WHERE o.user_id = 12345
AND o.create_time > NOW() - INTERVAL 30 DAY;
-- 说明：
-- LEADING(o d)：指定JOIN顺序，先处理o表（驱动表），再关联d表
-- USE_INDEX(o idx_user_status_time)：指定在o表上使用指定的索引
-- 这样可以确保优化器按照我们的预期来选择执行路径
-- 使用并行执行提升大查询性能
-- 对于需要扫描大量数据的分析查询，可以开启并行执行
SELECT /*+ PARALLEL(o 4) */
shop_id,
COUNT(*) AS order_count,
SUM(total_amount) AS total_sales
FROM t_order o
WHERE create_time > NOW() - INTERVAL 90 DAY
GROUP BY shop_id
ORDER BY total_sales DESC;
-- 说明：
-- PARALLEL(o 4)：指定对o表使用4个并行线程执行
-- 并行执行可以显著减少大查询的响应时间
-- 但要注意：并行度设置过高会消耗更多资源，需要根据实际情况调整
三、索引设计与执行计划分析
3.1 复合索引的设计原则
复合索引是OceanBase中最常用的索引类型，但设计不好反而会适得其反。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：复合索引设计的最佳实践
-- ============================================================
-- 原则1：把选择性高的字段放在前面
-- 选择性 = 不同值的数量 / 总行数
-- 选择性越高，索引过滤效果越好
-- 错误示范：把选择性低的字段放在最前面
-- status只有5种值，选择性极低，放在最前面效果很差
CREATE INDEX idx_bad_order ON t_order(status, user_id, create_time);
-- 说明：虽然也能查到数据，但索引的大部分空间都浪费在status上，
-- 对于同一个status值，后面还有大量其他user_id的记录，过滤效率低
-- 正确示范：把选择性高的字段放在最前面
DROP INDEX idx_bad_order ON t_order; -- 删除不好的索引
CREATE INDEX idx_good_order ON t_order(user_id, create_time, status);
-- 说明：
-- user_id选择性高（每个用户只有少量订单），放在最前面可以快速定位到特定用户的数据
-- create_time其次，用于时间范围过滤
-- status放在最后，作为辅助过滤条件
-- 原则2：注意前缀索引和排序字段的关系
-- 如果查询中有ORDER BY，可以把排序字段放在索引中，避免额外排序
-- 查询场景：查询用户最近100条订单，按时间倒序
-- 这个索引可以完美匹配这个查询，不需要额外排序
CREATE INDEX idx_user_time ON t_order(user_id, create_time DESC);
-- 说明：
-- DESC表示倒序，这样索引中的数据已经按照create_time倒序排列了
-- 查询时OceanBase可以直接按索引顺序读取，不需要额外的排序步骤
-- 验证：执行计划中应该没有"TABLE ACCESS SORT"或类似排序操作
EXPLAIN SELECT
order_id,
shop_id,
total_amount,
create_time
FROM t_order
WHERE user_id = 12345
ORDER BY create_time DESC
LIMIT 100;
3.2 区分聚簇索引和非聚簇索引
在OceanBase中，每张表的主键索引就是聚簇索引（Cluster Index），数据是按主键索引的叶子节点顺序存储的。理解聚簇索引和非聚簇索引的区别，对于索引设计非常重要。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：理解聚簇索引与非聚簇索引的区别
-- ============================================================
-- 聚簇索引（主键索引）：数据直接存储在索引的叶子节点中
-- 当表定义了PRIMARY KEY时，OceanBase会自动创建聚簇索引
CREATE TABLE t_account (
account_id BIGINT NOT NULL PRIMARY KEY, -- 这就是聚簇索引
user_id BIGINT NOT NULL,
balance DECIMAL(18,2) NOT NULL DEFAULT 0.00,
status TINYINT NOT NULL DEFAULT 1,
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ORGANIZATION INDEX;
-- 说明：
-- ORGANIZATION INDEX表示使用聚簇索引组织表数据
-- 数据的物理存储顺序按照account_id排序
-- 查询account_id范围时，数据在磁盘上是连续的，IO效率很高
-- 非聚簇索引（辅助索引）：索引的叶子节点存储的是主键值，而不是数据本身
CREATE INDEX idx_account_user ON t_account(user_id);
-- 说明：
-- 这个索引的叶子节点存储的是(user_id, account_id)
-- 当通过user_id查询时，OceanBase先在索引中找到account_id，
-- 然后再回表去聚簇索引中查找完整的数据行
-- 这就是"回表"操作，每次回表都需要额外读取数据页
-- 聚簇索引的优势在范围查询上体现得最明显
-- 查询某个ID范围内的账户（聚簇索引范围扫描，数据连续，效率高）
EXPLAIN SELECT
account_id,
balance
FROM t_account
WHERE account_id BETWEEN 10000 AND 10100;
-- 预期：Table Range Scan on primary index，数据在磁盘上连续，IO少
-- 非聚簇索引的范围查询需要额外的回表操作
EXPLAIN SELECT
account_id,
balance
FROM t_account
WHERE user_id = 12345;
-- 预期：先Index Range Scan on idx_account_user，然后Table Access回表
3.3 避免索引失效的场景
索引建好了不代表一定能用，有些写法会导致索引失效，退化为全表扫描。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：常见的索引失效场景
-- ============================================================
-- 场景1：对索引字段使用函数
-- 假设status字段有索引，但下面的写法会导致索引失效
CREATE INDEX idx_order_status ON t_order(status);
-- 错误写法：对索引字段使用了函数，索引失效
EXPLAIN SELECT * FROM t_order WHERE ABS(status) = 1;
-- 说明：ABS(status)导致优化器无法使用idx_order_status索引
-- 因为索引中的数据是原始的status值，不是ABS处理后的值
-- 正确写法：避免在索引字段上使用函数
EXPLAIN SELECT * FROM t_order WHERE status = 1;
-- 这样就能正确使用idx_order_status索引了
-- 场景2：隐式类型转换导致索引失效
-- 假设phone是VARCHAR类型但建有索引
-- 错误写法：传入数字类型，MySQL会做隐式转换，导致索引失效
EXPLAIN SELECT * FROM t_order WHERE user_id = '12345';
-- 说明：user_id是BIGINT，传入字符串'12345'会触发隐式类型转换
-- 虽然OceanBase通常能优化这种情况，但最好保持类型一致
-- 正确写法：保持类型一致
EXPLAIN SELECT * FROM t_order WHERE user_id = 12345;
-- 场景3：使用LIKE以%开头
-- 错误写法：前缀模糊查询，索引无法使用
EXPLAIN SELECT * FROM t_order WHERE remark LIKE '%关键词%';
-- 说明：%放在开头时，索引只能加速结尾的匹配，前缀%无法利用索引
-- 正确写法：前缀固定的模糊查询，索引可以使用
EXPLAIN SELECT * FROM t_order WHERE remark LIKE '关键词%';
-- 说明：前缀固定的LIKE可以利用B-Tree索引的前缀扫描
-- 场景4：使用OR连接非索引列
-- 假设只有user_id有索引，shop_id没有索引
EXPLAIN SELECT * FROM t_order WHERE user_id = 1 OR shop_id = 2;
-- 说明：OR连接的非索引列可能导致全表扫描
-- 如果两列都有索引，优化器可能使用Index Merge，但仍需注意效率
-- 优化写法：使用UNION ALL代替OR
EXPLAIN
(SELECT * FROM t_order WHERE user_id = 1)
UNION ALL
(SELECT * FROM t_order WHERE shop_id = 2);
-- 说明：UNION ALL让每个子查询都能独立使用索引
四、存储层配置优化
4.1 内存分配策略
OceanBase的内存管理是一个关键的性能影响因素。合理的内存配置可以让数据库充分利用服务器资源，同时避免内存不足导致的性能抖动。
# 技术栈：OceanBase (MySQL模式)
# ============================================================
# 示例：通过obd工具查看和调整内存配置
# ============================================================
# 查看当前集群的内存使用情况
obd cluster display oceanbase;
# 查看每个节点的内存分配情况
obd cluster display oceanbase -o observer.memory_limit;
# 调整Observer的内存上限
# 建议设置为服务器物理内存的70%~80%（预留一部分给操作系统和其他进程）
obd cluster edit-config oceanbase \
--set server.obmem_limit='16G' \
--reload;
# 查看内存分配详情（通过SQL查看）
# 连接到OceanBase后执行以下命令
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：通过系统视图查看内存分配
-- ============================================================
-- 查看当前节点的内存分配详情
-- 每个节点都会执行这个查询，返回的是本节点的内存信息
SELECT
zone,
svr_ip,
mem_limit,
mem_used,
mem_limit - mem_used AS mem_free,
ROUND(mem_used / mem_limit * 100, 2) AS usage_percent
FROM __all_virtual_memory_info
WHERE tenant_id = 1;
-- 说明：
-- __all_virtual_memory_info是OceanBase的虚拟内存信息表
-- mem_limit：该节点分配的内存上限
-- mem_used：当前使用的内存
-- 正常情况下内存使用率应该在60%~80%之间
-- 如果持续超过90%，说明内存分配不足，需要调大mem_limit
-- 查看各租户的内存使用情况
SELECT
tenant_id,
tenant_name,
mem_limit,
mem_used,
ROUND(mem_used / mem_limit * 100, 2) AS usage_percent
FROM __all_virtual_tenant_memory
ORDER BY mem_used DESC;
-- 说明：
-- 了解每个租户的内存使用比例，有助于判断是否需要重新分配内存
-- 如果某个租户内存经常打满，可以考虑增加该租户的内存配额
4.2 日志刷盘策略优化
OceanBase使用LSM-Tree结构存储数据，所有的写入操作都会先记录到日志中，然后异步刷盘。日志刷盘策略直接影响写入性能和数据安全性。
# 技术栈：OceanBase (MySQL模式)
# ============================================================
# 示例：日志刷盘策略的配置与调优
# ============================================================
# 查看当前的日志盘配置
obd cluster display oceanbase -o observer.log_disk_size;
# 查看日志盘使用率
obd cluster display oceanbase -o observer.log_disk_percentage;
# 日志盘空间不足时的扩展操作
# 注意：日志盘空间不足会导致数据库进入只读模式，必须及时处理
obd cluster edit-config oceanbase \
--set server.oblog_disk_size='500G' \
--reload;
# 查看日志写入延迟（通过sysbench或压测工具监控）
# 在压测时观察P99延迟是否因为日志刷盘出现毛刺
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：通过事务参数控制日志刷盘行为
-- ============================================================
-- 设置事务的隔离级别和日志策略
-- 读已提交级别（RC）比可重复读（RR）的写入性能更好，
-- 因为RC不需要维护快照读的undo链
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 说明：
-- READ COMMITTED：事务只能看到已提交的数据，适合读写混合场景
-- REPEATABLE READ：事务可以看到事务开始时的一致性快照，
-- 需要维护更多的undo信息，写入开销更大
-- 对于批量数据导入场景，可以临时关闭redo log
-- 注意：关闭redo log会牺牲数据持久性，仅用于可容忍数据丢失的场景
SET ob_trx_force_flush_log = 0;
-- 说明：
-- ob_trx_force_flush_log = 0：事务提交时不强制刷日志
-- 提高写入吞吐量，但断电时会丢失最近的事务
-- 适合ETL、数据同步等场景
-- 恢复默认值（强一致性，每条事务都刷日志）
SET ob_trx_force_flush_log = 1;
-- 说明：金融交易等强一致性场景必须保持这个设置
4.3 数据合并（Major Compaction）策略
OceanBase的LSM-Tree结构会产生大量的数据版本，需要通过合并操作来整理数据。合并策略直接影响系统的长期性能和稳定性。
# 技术栈：OceanBase (MySQL模式)
# ============================================================
# 示例：数据合并策略的配置与监控
# ============================================================
# 查看合并相关的系统参数
obd cluster display oceanbase -o observer.merge_schedule_interval;
# 查看合并进度（通过系统视图）
# 合并分为日常小合并（Minor Compaction）和定期大合并（Major Compaction）
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：合并策略的查看与优化
-- ============================================================
-- 查看最近的合并历史记录
SELECT
tenant_id,
status,
start_time,
end_time,
execution_time,
compaction_type,
result
FROM oceanbase.__all_virtual_compaction_history
WHERE tenant_id = 1
ORDER BY start_time DESC
LIMIT 20;
-- 说明：
-- 查看最近的合并记录，关注execution_time（合并耗时）和result（合并结果）
-- 如果合并耗时越来越长，说明数据增量在积累，可能需要调整合并频率
-- 查看当前是否有正在进行的合并
SELECT
tenant_id,
status,
start_time,
progress,
compaction_type
FROM oceanbase.__all_virtual_compaction_progress
WHERE tenant_id = 1;
-- 说明：
-- 如果合并一直在进行，说明合并的速度赶不上数据写入的速度
-- 这种情况需要增加合并资源或者减少数据写入量
-- 手动触发合并（通常在业务低峰期执行）
ALTER SYSTEM MAJOR FREEZE;
-- 说明：
-- MAJOR FREEZE触发一次大合并
-- 建议在业务低峰期执行，避免影响在线业务
-- 大合并会占用较多的CPU和IO资源
-- 设置自动合并的时间窗口
-- 通过配置让合并只在指定时间段内执行
ALTER SYSTEM SET merge_schedule_interval = '02:00:00~06:00:00';
-- 说明：
-- 设置合并只在凌晨2点到6点之间执行
-- 避免合并操作影响白天的业务性能
4.4 表组与数据分区优化
在分布式环境中，数据怎么分布直接影响查询和写入的性能。合理的分区策略可以让数据均匀分布，避免热点。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：数据分区策略与表组设计
-- ============================================================
-- 场景1：按时间范围分区（适合订单类数据）
CREATE TABLE t_order_partitioned (
order_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
shop_id BIGINT NOT NULL,
order_status TINYINT NOT NULL DEFAULT 0,
total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00,
create_time DATETIME NOT NULL,
PRIMARY KEY (order_id, create_time)
) PARTITION BY RANGE COLUMNS(create_time) (
PARTITION p202401 VALUES LESS THAN ('2024-02-01'),
PARTITION p202402 VALUES LESS THAN ('2024-03-01'),
PARTITION p202403 VALUES LESS THAN ('2024-04-01'),
PARTITION p202404 VALUES LESS THAN ('2024-05-01'),
PARTITION p_current VALUES LESS THAN MAXVALUE
);
-- 说明：
-- 按月份分区，每个分区只包含一个月的订单数据
-- 查询某个时间范围的订单时，只需要扫描对应的分区，不需要扫描整张表
-- 过期数据可以通过DROP PARTITION快速清理，不影响在线业务
-- 场景2：按哈希分区（适合需要均匀分布的场景）
CREATE TABLE t_user_account (
account_id BIGINT NOT NULL PRIMARY KEY,
user_id BIGINT NOT NULL,
balance DECIMAL(18,2) NOT NULL DEFAULT 0.00,
currency VARCHAR(10) NOT NULL DEFAULT 'CNY'
) PARTITION BY HASH(user_id) PARTITIONS 16;
-- 说明：
-- 按user_id的哈希值分成16个分区
-- 数据会均匀分布在不同分区中，避免热点
-- 每个分区可以分布在不同节点上，充分利用集群资源
-- 表组：把关联的表放在同一个表组中，确保它们的数据分布一致
-- 这样关联查询时不需要跨节点传输数据
ALTER TABLE t_order_partitioned SET GROUP 'order_group';
ALTER TABLE t_order_item SET GROUP 'order_group';
-- 说明：
-- 表组确保t_order和t_order_item的关联行分布在同一个节点上
-- JOIN操作不需要跨节点传输数据，性能提升显著
-- 但表组的代价是分区策略必须一致，灵活性降低
4.5 读写分离配置
OceanBase支持读写分离，将读操作路由到只读副本上，减轻主节点的压力。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：读写分离的配置与使用
-- ============================================================
-- 创建只读副本（在另一个Zone中）
-- 注意：需要在集群管理界面或通过obd创建
-- 这里展示的是验证和使用的SQL部分
-- 检查是否有多副本
SELECT
tenant_id,
zone,
svr_ip,
role
FROM __all_virtual_proxy_server_stat
WHERE tenant_id = 1;
-- 说明：
-- 查看当前集群中各节点的副本角色
-- LEADER：主副本，处理读写
-- FOLLOWER：备副本，可以处理读请求
-- 在应用层设置只读事务，OceanBase会自动路由到FOLLOWER
SET ob_read_consistency = 0;
-- 说明：
-- 0表示弱一致性读，允许读到稍旧的数据，可以路由到FOLLOWER
-- 1表示强一致性读，只能读LEADER的数据
-- 事务级别设置（推荐用法）
-- 在事务开始时指定读模式，事务内部的所有查询都使用这个模式
BEGIN;
SET ob_read_consistency = 0;
SELECT * FROM t_order WHERE user_id = 12345;
COMMIT;
-- 说明：
-- 通过事务级别的设置，可以把非实时性的读请求路由到备副本
-- 实时性要求高的读请求仍然保持强一致性，确保数据正确性
五、应用场景深度分析
5.1 电商下单场景的优化实践
电商下单是典型的写密集场景，需要同时满足高并发写入和毫秒级响应。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：电商下单场景的SQL优化
-- ============================================================
-- 场景描述：用户下单时，需要同时操作多张表
-- 1. 创建订单 2. 创建订单明细 3. 扣减库存 4. 扣减余额
-- 使用单个事务保证数据一致性
START TRANSACTION;
-- 步骤1：插入订单主表
INSERT INTO t_order (user_id, shop_id, order_status, total_amount, create_time)
VALUES (10001, 2001, 0, 299.00, NOW());
-- 说明：order_status = 0表示待支付
-- 使用NOW()而不是在应用层生成时间，减少网络传输和序列化开销
-- 步骤2：插入订单明细（获取上一步生成的自增ID）
INSERT INTO t_order_item (order_id, product_id, quantity, price) VALUES
(LAST_INSERT_ID(), 30001, 1, 199.00),
(LAST_INSERT_ID(), 30002, 2, 50.00);
-- 说明：LAST_INSERT_ID()获取刚才INSERT生成的自增主键
-- 步骤3：扣减库存（使用条件更新防止超卖）
UPDATE t_product SET
stock = stock - 3
WHERE product_id = 30001
AND stock >= 3;
-- 说明：
-- 关键：AND stock >= 3 这个条件防止超卖
-- 如果stock不足，UPDATE影响行数为0，事务会回滚
UPDATE t_product SET
stock = stock - 2
WHERE product_id = 30002
AND stock >= 2;
-- 步骤4：扣减用户余额
UPDATE t_account SET
balance = balance - 299.00
WHERE user_id = 10001
AND balance >= 299.00;
-- 说明：同样使用条件更新防止余额不足
-- 检查库存扣减是否成功（通过affected_rows判断）
-- 如果任何一条UPDATE影响行数为0，说明库存或余额不足，需要回滚
-- 在应用层检查每条语句的affected_rows
COMMIT;
-- 说明：
-- 整个下单过程在一个事务中完成，保证数据一致性
-- 事务内操作越少越好，每增加一个操作都会增加锁持有时间
-- 优化建议：
-- 1. 事务内只放必要的操作，查询操作尽量放到事务外面
-- 2. 库存扣减可以异步处理，先创建订单，库存异步扣减
-- 3. 使用乐观锁（条件更新）而不是悲观锁，减少锁冲突
-- 优化后的异步下单流程
-- 步骤1：同步创建订单（快速返回给用户）
INSERT INTO t_order (user_id, shop_id, order_status, total_amount, create_time)
VALUES (10001, 2001, 0, 299.00, NOW());
COMMIT;
-- 步骤2：发送消息到消息队列，异步处理库存扣减
-- 步骤3：定时任务或消息消费者处理库存和余额扣减
-- 说明：
-- 这种异步方案将下单响应时间从数百毫秒降低到几十毫秒
-- 但需要处理消息丢失、重复消费等问题
5.2 金融交易场景的优化实践
金融交易要求强一致性，不能使用最终一致性的异步方案。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：金融转账场景的SQL优化
-- ============================================================
-- 场景：用户A向用户B转账1000元
-- 要求：强一致性，不能出现钱扣了但对方没收到，或重复转账
START TRANSACTION;
-- 步骤1：锁定A的账户并扣款（使用SELECT ... FOR UPDATE）
SELECT balance FROM t_account
WHERE user_id = 10001
FOR UPDATE;
-- 说明：
-- FOR UPDATE会对查询结果加排他锁，防止并发修改
-- 获取到锁后再检查余额是否充足
-- 步骤2：检查余额（应用层判断）
-- 如果余额 >= 1000，执行扣款；否则回滚事务
UPDATE t_account SET balance = balance - 1000.00
WHERE user_id = 10001;
-- 步骤3：给B账户加款
UPDATE t_account SET balance = balance + 1000.00
WHERE user_id = 10002;
-- 步骤4：记录交易流水（审计日志）
INSERT INTO t_transaction_log (
transaction_id, from_user, to_user, amount, create_time
) VALUES (
UUID(), 10001, 10002, 1000.00, NOW()
);
COMMIT;
-- 说明：
-- 金融场景必须使用强一致性隔离级别
-- SELECT ... FOR UPDATE 用于锁定关键行，防止并发问题
-- 注意：FOR UPDATE持有的锁在事务结束前不会释放
-- 锁持有时间越长，并发冲突的概率越高
-- 优化建议：
-- 1. 事务内操作越少越好，缩短锁持有时间
-- 2. 避免在事务内执行耗时操作（如外部API调用）
-- 3. 考虑使用乐观锁减少锁冲突：
-- UPDATE t_account SET balance = balance - 1000
-- WHERE user_id = 10001 AND balance >= 1000;
-- 这样不需要FOR UPDATE，通过affected_rows判断是否成功
-- 乐观锁方案的实现
START TRANSACTION;
-- 直接更新，通过WHERE条件检查余额
UPDATE t_account SET balance = balance - 1000.00
WHERE user_id = 10001 AND balance >= 1000.00;
-- 应用层检查：如果affected_rows = 1，成功；= 0，余额不足
UPDATE t_account SET balance = balance + 1000.00
WHERE user_id = 10002;
INSERT INTO t_transaction_log (transaction_id, from_user, to_user, amount, create_time)
VALUES (UUID(), 10001, 10002, 1000.00, NOW());
COMMIT;
-- 说明：
-- 乐观锁方案不需要FOR UPDATE，并发性能更好
-- 但在高争用场景（同一个账户频繁操作）下，
-- 乐观锁的失败率可能较高，需要考虑重试机制
六、技术优缺点对比
6.1 索引优化的优缺点
索引是OceanBase性能优化的核心手段，但它不是免费的午餐。
优点方面：索引能显著减少数据扫描量，一条SQL从扫描百万行变成扫描几十行，查询速度可以提升数百倍。覆盖索引还能避免回表，进一步提升查询效率。在OceanBase的分布式架构中，索引还能帮助优化器选择正确的并行策略，减少跨节点数据传输。
缺点方面：每个索引都会增加写入开销，因为每次INSERT、UPDATE、DELETE都需要维护索引的B-Tree结构。索引会占用额外的存储空间，在数据量大的表上，多个索引可能让存储成本翻倍。在OceanBase的分布式场景中，过多索引还会增加合并操作的开销，因为每个索引都需要参与合并。
6.2 存储层优化的优缺点
存储层优化的效果通常不如SQL优化来得直观，但它是系统性能的基础保障。
优点方面：合理的内存分配可以避免频繁的数据换入换出，提升缓存命中率。优化合并策略可以减少系统抖动，让性能更加稳定。分区策略可以大幅提升大表的查询效率，避免全表扫描。
缺点方面：存储层配置错误可能导致严重后果，比如内存分配过大导致操作系统OOM（内存溢出）。分区设计不当会造成数据倾斜，让某些节点负载过重。合并策略调整需要理解LSM-Tree的内部机制，否则可能适得其反。
6.3 读写分离的优缺点
优点方面：读写分离可以有效缓解主节点的读压力，让写入性能不受读请求影响。备副本可以承担大部分分析型查询，不影响核心交易。
缺点方面：读写分离会引入数据延迟，备副本的数据可能比主副本稍旧。如果需要读自己的写（Read Your Write），可能会读到旧数据。备副本的维护也需要额外的存储和计算资源。
七、实战注意事项
7.1 性能压测是优化的基础
做任何优化之前，必须先做性能压测，找到真正的瓶颈所在。
# 技术栈：OceanBase (MySQL模式)
# ============================================================
# 示例：使用sysbench进行性能压测
# ============================================================
# 安装sysbench
yum install sysbench -y;
# 准备测试数据（创建测试表并填充数据）
sysbench oltp_read_write prepare \
--mysql-host=127.0.0.1 \
--mysql-port=2881 \
--mysql-user=root@tenant \
--mysql-password=your_password \
--tables=10 \
--table-size=1000000;
# 说明：
# 创建10张表，每张表100万行数据
# 模拟真实的业务数据规模
# 注意：prepare会创建表并插入数据，需要确保有足够的磁盘空间
# 执行压测（模拟读写混合负载）
sysbench oltp_read_write run \
--mysql-host=127.0.0.1 \
--mysql-port=2881 \
--mysql-user=root@tenant \
--mysql-password=your_password \
--tables=10 \
--table-size=1000000 \
--threads=64 \
--time=60 \
--report-interval=5;
# 说明：
# --threads=64：64个并发线程
# --time=60：压测持续60秒
# --report-interval=5：每5秒报告一次结果
# 关注指标：TPS（每秒事务数）、QPS（每秒查询数）、P99延迟
# 清理测试数据
sysbench oltp_read_write cleanup \
--mysql-host=127.0.0.1 \
--mysql-port=2881 \
--mysql-user=root@tenant \
--mysql-password=your_password \
--tables=10;
7.2 渐进式优化原则
性能优化是一个持续的过程，不能一次性做完所有优化。推荐按照以下顺序逐步优化：
第一步：SQL层优化 —— 分析慢查询日志，找到最耗时的SQL，优化索引和写法。这一步投入最小，收益最大。
第二步：执行计划调优 —— 对于无法通过SQL改写解决的执行计划问题，使用Hint引导优化器。
第三步：存储层配置 —— 调整内存分配、合并策略等参数。这一步需要谨慎，每次只改一个参数，观察效果。
第四步：架构层面优化 —— 读写分离、分区优化、缓存引入等架构级别的调整。这一步的改动最大，需要充分测试。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：慢查询日志分析
-- ============================================================
-- 查看最近的慢查询
SELECT
query_sql,
execution_time,
rows_returned,
rows_read,
plan_id
FROM oceanbase.__all_virtual_slow_query_audit
WHERE tenant_id = 1
AND execution_time > 1000000 -- 超过1秒的查询
ORDER BY execution_time DESC
LIMIT 50;
-- 说明：
-- 慢查询日志是优化的起点
-- 重点关注execution_time（执行时间）、rows_read（扫描行数）
-- rows_read远大于rows_returned说明有很多无效扫描，需要优化索引
-- 查看某条SQL的历史执行记录
SELECT
query_sql,
execution_time,
rows_returned,
request_time
FROM oceanbase.__all_virtual_sql_audit
WHERE tenant_id = 1
AND query_sql LIKE 'SELECT%FROM t_order%WHERE user_id%'
ORDER BY request_time DESC
LIMIT 100;
-- 说明：
-- 查看同一条SQL在不同时间段的执行表现
-- 如果执行时间忽快忽慢，可能是统计信息过期或者并发争用导致的
-- 收集统计信息（帮助优化器做出更好的决策）
ANALYZE TABLE t_order COMPUTE STATISTICS;
ANALYZE TABLE t_order_item COMPUTE STATISTICS;
-- 说明：
-- 统计信息是优化器选择执行计划的基础
-- 数据量变化大后需要重新收集统计信息
-- 建议在数据变更大的时间段后执行（如批量导入后）
7.3 监控与告警
性能优化不是一次性的工作，需要建立完善的监控体系来持续跟踪系统状态。
-- 技术栈：OceanBase (MySQL模式)
-- ============================================================
-- 示例：关键性能指标的监控查询
-- ============================================================
-- 1. 查看集群整体负载（CPU、IO、网络）
SELECT
svr_ip,
cpu_usage,
io_read_bytes,
io_write_bytes,
net_in_bytes,
net_out_bytes
FROM __all_virtual_sysstat
WHERE tenant_id = 1
AND stat_name IN ('CPU', 'IOPS_READ', 'IOPS_WRITE', 'NET_IN', 'NET_OUT');
-- 说明：
-- CPU使用率超过80%需要关注
-- IO读写量突然飙升可能是合并操作或慢查询导致的
-- 2. 查看活跃会话数
SELECT
tenant_id,
session_id,
user_name,
sql_text,
start_time,
status
FROM __all_virtual_processlist
WHERE tenant_id = 1
AND status = 'ACTIVE';
-- 说明：
-- 活跃会话数过多说明并发压力太大
-- 关注长时间活跃的会话，可能是慢查询
-- 3. 查看事务状态
SELECT
tenant_id,
tx_id,
session_id,
tx_status,
start_time,
tx_participants,
tx_elapsed_time
FROM __all_virtual_trans_state
WHERE tenant_id = 1
ORDER BY tx_elapsed_time DESC
LIMIT 20;
-- 说明：
-- 关注长时间未提交的事务
-- 长时间事务会占用内存和锁资源，影响其他事务的性能
八、文章总结
OceanBase的核心交易场景性能优化是一个系统工程，需要从SQL编写、索引设计、存储层配置三个维度来综合考虑。
从SQL层面来说，最重要的是消除全表扫描、使用覆盖索引、减少不必要的事务操作。SQL优化是最直接、最容易见效的手段，但它的效果有上限——当SQL已经足够优化后，就需要从更深层来挖掘性能。
从索引设计来说，关键在于理解B-Tree索引的工作方式、合理设计复合索引的字段顺序、避免索引失效的场景。索引是双刃剑，用得好是性能加速器，用得不好是写入性能的杀手。
从存储层配置来说，合理的内存分配、日志刷盘策略、数据合并策略是系统稳定运行的基础。这些配置需要结合具体的业务场景和硬件环境来调整，不能照搬模板。
最后想说的是，性能优化没有终点。业务数据量在增长，技术架构在演进，今天的优化方案可能明天就不够用了。建立完善的监控体系、定期进行性能评估、持续进行优化迭代，才是长期保持系统高性能的关键。
记住一个原则：先测量，再优化。不要凭感觉去调参数，先通过压测找到真正的瓶颈，然后有针对性地优化。每一次优化都应该有明确的指标来衡量效果，避免"优化了但不确定有没有用"的情况。
评论
围绕“OceanBase核心交易场景下性能优化：从SQL调优到存储层配置的全链路方案”参与讨论