1. 项目概述为什么一个数据库性能测试值得专门写一篇实操笔记OceanBase 2.2 这个版本在业内有个很实在的标签——“从金融核心场景反向锤炼出来的稳定器”。它不是靠PPT参数堆出来的而是某大型支付平台在双十一流量洪峰下连续三年零故障跑出来的。所以当我在实验室环境里第一次把JMeter脚本往OceanBase 2.2集群上压的时候心里想的不是“能不能跑通”而是“它会不会在某个并发阈值突然抖一下暴露底层事务调度的真实水位线”。这个项目标题看着简单但背后藏着三层硬核动作第一层是环境对齐——OceanBase 2.2 的租户模型、资源隔离粒度、SQL兼容性边界和MySQL 5.7并不完全等价直接套用老MySQL压测脚本会漏掉关键瓶颈第二层是指标可信——TPS、平均响应时间这些数字谁都会看但OceanBase特有的“OBServer CPU饱和度”“日志流同步延迟”“LSLog Stream堆积量”才是判断真实承载力的黄金三指标第三层是问题归因闭环——JMeter只告诉你“慢了”而OceanBase的observer.log、obproxy.log、以及system tenant里的gv$sysstat视图才真正告诉你“慢在哪一环”。我做这个测试的原始动机很朴素某高校实验室要部署一套教学用分布式数据库沙箱要求学生能直观看到“分库分表”和“透明分布式”两种架构在相同压力下的行为差异。OceanBase 2.2 是当时唯一能把“分布式事务一致性”和“单机MySQL语法兼容性”同时做到教学级易用的开源选项。所以这篇笔记不是给DBA看的调优手册而是给刚接触分布式数据库的开发者、运维、甚至课程设计者准备的一份“可触摸的性能认知地图”——你知道每一步操作在动什么、改什么、影响什么而不是盲目点下“Start Thread Group”。关键词里没提但必须前置强调的三个硬约束必须用OceanBase官方提供的obclient而非mysql-client连接否则会绕过OBProxy的路由逻辑测的其实是单节点JMeter的CSV Data Set Config必须开启“Recycle on EOF False”OceanBase 2.2的prepare语句缓存机制对重复SQL有强依赖循环读取会导致连接池雪崩所有SQL必须显式指定USE DATABASEOB 2.2的默认租户模式下跨库查询不走全局索引容易误判为SQL解析慢。这三个点我在第一轮测试里全踩过加起来浪费了17小时——这比写脚本花的时间还多。2. 整体设计思路与方案选型逻辑2.1 为什么不用Sysbench而坚持用JMeter很多人看到数据库压测第一反应是Sysbench但这次我刻意绕开了它。原因很实际Sysbench的Lua脚本虽然灵活但它对OceanBase 2.2特有的多租户资源组绑定、SQL Plan Baseline强制走索引、分区键自动路由验证这些能力缺乏原生支持。举个例子Sysbench的oltp_read_write.lua默认用sbtest表而OceanBase 2.2要求分区表必须显式声明PARTITION BY KEY或PARTITION BY HASHSysbench生成的建表语句不带这个你得手动改源码重新编译——这对教学环境来说太重了。JMeter的优势在于“可视化可调试”。学生可以清楚看到Thread Group里50个线程启动后每个HTTP Request这里模拟的是JDBC请求的响应时间散点图View Results Tree里能逐条展开SQL执行计划Aggregate Report里能对比不同租户sys、test_tenant的错误率差异。更重要的是JMeter的JSR223 PreProcessor可以直接调用Java API获取OceanBase的gv$session_wait视图数据实现“压测中实时抓取等待事件”——这是Sysbench做不到的深度可观测性。提示JMeter本身不处理数据库协议它依赖JDBC Driver。OceanBase 2.2必须用oceanbase-client-2.2.0.jar不能用mysql-connector-java-8.0.28.jar。后者虽然能连上但会把INSERT ... ON DUPLICATE KEY UPDATE识别成两条独立语句导致事务拆分测出来的是网络往返延迟不是真实OLTP吞吐。2.2 测试场景设计不是越复杂越好而是要打中要害我最终锁定了三个递进式场景每个都对应OceanBase 2.2的一个关键设计哲学场景A单表主键点查SELECT * FROM t_user WHERE id ?目标是验证“分区键路由效率”。OceanBase 2.2的t_user表按id哈希分区这个SQL应该100%命中目标分区不产生跨机网络开销。如果响应时间超过5ms说明OBServer的RPC线程池或内存分配有问题。场景B二级索引范围扫描SELECT * FROM t_order WHERE user_id ? AND create_time ?目标是验证“索引组织表IOT 全局索引”的协同效率。OceanBase 2.2的t_order表主键是(order_id)但建了全局索引(user_id, create_time)。这个查询会先走全局索引定位分区再回表取数据——正是分布式数据库最怕的“两跳”操作。我们看TPS衰减拐点在哪。场景C跨租户分布式事务BEGIN; INSERT INTO sys.t_config VALUES(...); INSERT INTO test_tenant.t_log VALUES(...); COMMIT;目标是验证“多租户事务协调器TX Coordinator”的负载能力。OceanBase 2.2的事务不是单机ACID而是基于Paxos多数派的日志同步。这个场景会强制触发跨租户日志流同步暴露LS堆积风险。这三个场景的QPS阶梯设置也花了心思不是简单地从100→1000→5000线性加压而是按OceanBase 2.2的默认配置反推——它的net_thread_count默认是4rpc_packet_queue_size是16384理论单机最大并发连接数约3200。所以我把阶梯设为300 → 900 → 1800 → 2700 → 3000。每档压测5分钟留出30秒缓冲期让系统收敛。这样做的好处是你能清晰看到在2700并发时OBServer的CPU使用率是否突破85%以及gv$sysstat里log_sync_time指标是否开始跳变。2.3 工具链组合为什么选这四件套整个技术栈我只用了四个核心组件但每个都经过血泪验证JMeter 5.4.3必须用这个版本。5.5引入了新的JDBC Connection Pool实现和OceanBase 2.2的连接复用机制有兼容问题会导致Connection reset错误率飙升。5.4.3的org.apache.jmeter.protocol.jdbc.config.DataSourceElement类对maxOpenPrepStatements参数控制最稳。OceanBase 2.2.70这是2.2系列最后一个稳定版。2.2.50存在一个已知Bug当JMeter启用Keep-Alive时OBProxy会错误复用同一连接执行不同租户的SQL造成权限校验失败。70版修复了这个且日志格式统一为JSON方便ELK采集。obclient 2.2.0不是为了替代JMeter而是用于压测间隙的快速诊断。比如JMeter报告TPS骤降我立刻切到终端执行obclient -h obproxy_ip -P 2883 -u roottest_tenant#cluster_name -p xxx -c -D test_db -e select * from gv$sysstat where stat_name like log%;10秒内就能定位是日志刷盘慢还是网络延迟高。Grafana Prometheus OceanBase Exporter这是真正的“上帝视角”。OceanBase官方Exporter会把__all_virtual_sysstat、__all_virtual_processlist等内部视图转成Prometheus指标。我在Grafana里建了三个核心面板① OBServer CPU利用率热力图按机器IP分色② 每秒LS同步延迟折线图阈值标红为50ms③ 租户级内存使用TOP5避免test_tenant吃光sys租户内存。没有这个组合你就是在盲人摸象。注意OceanBase Exporter的collect.interval必须设为10s不能设成5s。实测发现5s采集频率会导致Exporter自身CPU占用超40%干扰OBServer的性能表现属于典型的“测量工具污染被测对象”。3. 核心细节解析与实操要点3.1 环境准备三台机器的最小可行集群怎么搭才不翻车OceanBase 2.2的“最小生产可用集群”是3台机器1个OCP管理节点 2个OBServer但教学实验我压缩到了纯三节点OBServer集群不装OCP——因为OCP本身会占用1.5GB内存而我们的虚拟机只有4GB/台。具体配置如下角色IP内存磁盘关键配置项OBServer-1192.168.1.104GB/data/1: 50GB SSDmemory_limit2G,system_memory512M,cpu_count2OBServer-2192.168.1.114GB/data/2: 50GB SSDmemory_limit2G,system_memory512M,cpu_count2OBServer-3192.168.1.124GB/data/3: 50GB SSDmemory_limit2G,system_memory512M,cpu_count2这里有个极易被忽略的细节system_memory必须严格等于memory_limit的25%。OceanBase 2.2的内存管理是硬划分的system_memory专供内部元数据、日志缓冲区使用。如果设成400M小于512M启动时会报[ERROR] system memory not enough for observer如果设成600M大于512M则用户SQL内存池会被严重挤压TPS直接腰斩。这个比例是官方文档里写的但很多教程直接抄错成“建议值”导致集群看似启动成功实则性能残缺。初始化集群的命令必须用obd cluster deploy不能手写start_observer.sh。因为OBD会自动校验三台机器的ntpd服务状态、ulimit -n是否≥65535、/proc/sys/net/core/somaxconn是否≥65535。我第一次手启失败就是因为/proc/sys/net/core/somaxconn默认是128OBServer监听端口队列瞬间塞满JMeter连接全部超时。租户创建环节我建了两个租户sys_tenant资源单元unit_config_1CPU1, MEMORY1G用于存放系统表和监控数据test_tenant资源单元unit_config_2CPU2, MEMORY2G这才是JMeter压测的目标。关键命令# 创建租户时必须指定resource_pool_list否则默认绑到sys租户 obclient -h 192.168.1.10 -P 2883 -u rootsys -p ****** -c -e CREATE RESOURCE UNIT unit_config_2 MAX_CPU 2, MIN_CPU 2, MEMORY_SIZE 2G, LOG_DISK_SIZE 10G; CREATE RESOURCE POOL pool_test UNIT unit_config_2, UNIT_NUM 1, ZONE_LIST (zone1,zone2,zone3); CREATE TENANT test_tenant RESOURCE_POOL_LIST (pool_test) SET VARIABLES ob_compatibility_modemysql; 实操心得ob_compatibility_modemysql必须显式设置OceanBase 2.2默认是oracle模式LIMIT语法不支持INSERT IGNORE会报错。这个参数一旦设错JMeter脚本里所有SQL都要重写别问我是怎么知道的。3.2 JMeter脚本构建从零开始的五个不可跳过的配置JMeter的JDBC Request元件看着简单但OceanBase 2.2的适配需要五个关键配置点缺一不可第一JDBC Connection ConfigurationDatabase URLjdbc:oceanbase://192.168.1.10:2883/test_db?useSSLfalseallowMultiQueriestruerewriteBatchedStatementstrue注意必须用jdbc:oceanbase://前缀这是oceanbase-client的专属协议allowMultiQueriestrue允许一条语句执行多个SQL如BEGIN; INSERT; COMMITrewriteBatchedStatementstrue开启批量插入优化否则每条INSERT都走独立网络包。JDBC Driver classcom.alipay.oceanbase.jdbc.Driver不是com.mysql.cj.jdbc.Driver后者会把OceanBase识别成MySQL 5.6禁用所有2.2新特性。第二Variable Bindings预编译参数OceanBase 2.2的PrepareStatement缓存是按SQL文本哈希的。如果你在JDBC Request里写SELECT * FROM t_user WHERE id ${id}每次${id}变化都会生成新缓存条目内存爆满。正确做法是在JDBC Request的Parameter Values里填12345在Parameter Types里填BIGINTSQL正文写死SELECT * FROM t_user WHERE id ?这样OceanBase只缓存一条执行计划复用率100%。第三Response Assertion结果校验加一个“响应断言”检查Response Message是否包含Query OK或Affected rows。这不是为了测功能而是防“静默失败”——OceanBase 2.2在LS堆积严重时会返回ERROR 4012 (HY000): Transaction is rolled back due to log sync timeout但JMeter默认不报错TPS虚高。断言能立刻捕获这类异常。第四Timer节奏控制必须加Constant Timer设为100ms。理由很现实OceanBase 2.2的RPC超时默认是1000ms如果JMeter线程不加间隔瞬间涌进3000个请求OBServer的net_thread_count队列会积压后续请求全部排队测出来的是线程调度延迟不是SQL执行延迟。100ms间隔能让请求均匀分布逼近真实业务流量模型。第五Listener结果采集除了常规的View Results Tree和Aggregate Report必须加一个Backend Listener配置Prometheus Pushgateway地址。这样JMeter每30秒就把Transactions per Second、Average Response Time推送到Pushgateway和OceanBase Exporter的数据在Grafana里同屏对比——你才能看出“TPS下降时到底是SQL慢了还是网络卡了”。3.3 SQL脚本与数据构造为什么10万行数据是甜点值数据量不是越多越好。我试过100万行t_user表结果发现OceanBase 2.2的__all_virtual_table元数据加载耗时超8秒JMeter还没开始压测OBServer已经在后台疯狂刷脏页。最终锁定10万行为黄金数据量依据是OceanBase 2.2的默认配置micro_block_size 16KBmacro_block_size 2MB单个宏块Macro Block最多存128个微块Micro Block10万行用户数据按每行200字节估算总大小约20MB刚好占10个宏块。OceanBase 2.2的LSLog Stream刷盘是以宏块为单位的10个宏块意味着日志流同步压力可控不会触发频繁的log_sync阻塞。建表语句必须带分区定义CREATE TABLE t_user ( id BIGINT NOT NULL PRIMARY KEY, name VARCHAR(64), email VARCHAR(128), create_time DATETIME ) PARTITION BY HASH(id) PARTITIONS 4;注意PARTITIONS 4——这是为了匹配三节点集群的Paxos组。OceanBase 2.2要求分区数必须是3的倍数或质数4是安全值。如果写PARTITIONS 3当一台OBServer宕机时剩余两台无法形成多数派整个分区不可写JMeter会持续报ERROR 4013 (HY000): Not enough replicas for partition。数据插入用JMeter的JSR223 Sampler执行批量SQLdef sql INSERT INTO t_user VALUES def values [] for (int i 1; i 1000; i) { def id vars.get(counter) as int i values ($id, user_${id}, u${id}test.com, NOW()) } sql values.join(,) // 执行前清空连接缓存避免长连接老化 props.put(jdbc.connection.clear, true) WDS.sampleResult.setResponseMessage(Inserted 1000 rows)这里props.put(jdbc.connection.clear, true)是关键。OceanBase 2.2的连接池在长时间空闲后会自动关闭物理连接但JMeter的JDBC Connection Configuration元件不知道下次复用时会抛Connection closed异常。主动清空缓存强制重建连接TPS曲线才平滑。4. 实操过程与核心环节实现4.1 第一轮压测单表点查的“教科书级”性能曲线我把JMeter的Thread Group设为线程数300Ramp-Up Period 60秒循环次数Forever。这是为了观察系统从冷启动到稳态的全过程。前60秒Ramp-Up阶段TPS从0缓慢爬升到1200平均响应时间从8ms降到3.2ms。这个下降不是因为SQL变快了而是OceanBase 2.2的Plan Cache预热在起作用。gv$sql_audit视图显示前1000次查询的EXECUTIONS为1之后EXECUTIONS突增到100说明执行计划被复用。此时gv$plan_cache_stat的HIT_RATE从20%跳到92%。60-300秒稳态阶段TPS稳定在1250±15响应时间恒定在3.1±0.3ms。这时看Grafana面板OBServer CPU利用率62%LS同步延迟5msgv$sysstat里log_sync_time指标平稳在0.8ms。一切完美——但这恰恰是陷阱。实操心得OceanBase 2.2的“稳态”往往藏在第一个拐点之后。我故意把Ramp-Up时间拉长到60秒就是为了逼出Plan Cache的临界点。很多教程测出1250 TPS就宣布成功但没测过3000并发下的表现。真正的压力测试是要找到那个让系统开始“喘不过气”的精确阈值。300秒后拐点出现TPS突然跌到1180响应时间跳到4.7ms。我立刻切到obclient查gv$session_waitSELECT event, wait_time_micro, p1text, p1 FROM gv$session_wait WHERE state WAITING AND event NOT LIKE idle% ORDER BY wait_time_micro DESC LIMIT 5;结果前三名全是log file syncwait_time_micro平均值达1200012ms。这说明LS刷盘成了瓶颈。根本原因不是磁盘慢而是OceanBase 2.2的log_disk_utilization_threshold默认是80%当日志盘使用率超80%时会主动限速保护。我查df -h /data/1果然日志盘/data/1/log使用率82%。解决方案不是扩容而是调大log_disk_utilization_threshold到90%并重启OBServer。4.2 第二轮压测二级索引扫描的“两跳”代价量化场景B的SQL是SELECT * FROM t_order WHERE user_id ? AND create_time ?。这里的关键是t_order表的结构CREATE TABLE t_order ( order_id BIGINT NOT NULL PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2), create_time DATETIME, INDEX idx_user_time (user_id, create_time) GLOBAL ) PARTITION BY HASH(order_id) PARTITIONS 4;注意INDEX ... GLOBAL——这是OceanBase 2.2的全局索引数据分散在所有分区查询时必须先查索引表定位分区再回表取数据典型的“两跳”。我把JMeter线程数提到900其他不变。结果TPS卡在820响应时间飙升到18ms。gv$plan_cache_plan_explain显示执行计划是| ID | OPERATOR | NAME | ROWS | COST | |----|--------------------|-----------------|------|------| | 0 | EXCHANGE IN DISTR | | 100 | 100 | | 1 | EXCHANGE OUT DISTR | | 100 | 100 | | 2 | TABLE SCAN | t_order(idx_user_time) | 100 | 100 | | 3 | TABLE GET | t_order | 1 | 5 |TABLE SCAN走的是全局索引TABLE GET是回表。问题出在第2步OceanBase 2.2的全局索引扫描是广播式的会把查询条件发给所有分区每个分区都扫描自己的索引段再汇总结果。900并发下网络带宽被打满。解决方案是加/* USE_INDEX(t_order, idx_user_time) */提示并在JDBC URL里加enable_ob_routetrue。前者强制走索引后者启用OBProxy的智能路由让查询只发给可能包含数据的分区。改完后TPS升到1150响应时间降到9ms。注意enable_ob_routetrue必须配合obclient或oceanbase-client驱动mysql-connector不识别这个参数。这是OceanBase 2.2独有的路由优化普通MySQL压测根本用不到。4.3 第三轮压测跨租户事务的“隐形墙”突破场景C是最狠的——它同时压测了OceanBase 2.2的三大核心模块SQL引擎、事务协调器、日志同步。JMeter脚本里我用JSR223 PreProcessor动态切换连接// 根据线程ID奇偶性一半连sys租户一半连test_tenant def tenant (vars.get(threadNum).toInteger() % 2 0) ? sys : test_tenant vars.put(tenant, tenant) WDS.sampleResult.setResponseMessage(Using tenant: ${tenant})然后JDBC Request的Database URL动态拼接jdbc:oceanbase://192.168.1.10:2883/${tenant}?...压到2700并发时TPS断崖式下跌到320错误率100%。obclient查gv$sysstat发现trans_commit_time指标暴涨到200mslog_sync_time超200ms。但Grafana显示OBServer CPU才70%磁盘IO正常。问题出在gv$transaction视图SELECT trans_id, tenant_id, state, start_time, wait_event FROM gv$transaction WHERE state ACTIVE AND wait_event LIKE %log%;结果全是log sync wait且tenant_id混着sys和test_tenant。真相是OceanBase 2.2的事务协调器TX Coordinator在跨租户时必须等两个租户的日志都刷到多数派节点才算成功。而sys租户的LS优先级更高test_tenant的日志被排队形成“木桶效应”。解决方法是给test_tenant单独配高优先级LSALTER SYSTEM SET log_disk_utilization_threshold 90 FOR TENANT test_tenant; ALTER SYSTEM SET log_disk_usage_limit_percentage 95 FOR TENANT test_tenant;再压测TPS回升到680虽未达单租户水平但错误率为0。这证明OceanBase 2.2的跨租户事务不是不能做而是需要精细的资源隔离策略。5. 常见问题与排查技巧实录5.1 JMeter报错“Connection refused: connect”——八成是OBProxy没起来这个错误看似是网络问题实则是OceanBase 2.2的代理层故障。OBProxy是无状态的但它的配置文件etc/obproxy.conf里有一行rs_list192.168.1.10:2882;192.168.1.11:2882;192.168.1.12:2882如果其中任意一台OBServer的rpc_port默认2882没监听OBProxy启动时会静默失败ps aux | grep obproxy能看到进程但netstat -tlnp | grep 2883没有监听。正确排查顺序curl -s http://127.0.0.1:2884/status查OBProxy健康状态返回{status:active}才正常如果失败tail -f log/obproxy.log看最后一行是否含fail to connect to rs登录对应OBServernetstat -tlnp | grep 2882确认端口监听若未监听ps aux | grep observer看进程是否存在不存在则cd /home/admin/oceanbase ./bin/start_observer.sh实操心得OBProxy的rs_list必须写IP不能写hostname。OceanBase 2.2的DNS解析在OBProxy里是同步阻塞的如果hostname解析超时3sOBProxy直接退出。我曾因/etc/hosts里少了一行映射折腾了4小时。5.2 TPS上不去但CPU和IO都很低——去查gv$memstore_info这是OceanBase 2.2最隐蔽的瓶颈。当gv$memstore_info里used_memstore接近memstore_limit默认是memory_limit的50%时OceanBase会主动冻结MemStore触发强制刷盘。此时SQL还在执行但新写入被阻塞TPS停滞。现象是JMeter的Active Threads卡在某个值不动响应时间忽高忽低而top看CPU很低。查证命令SELECT tenant_id, used_memstore, memstore_limit, ROUND(used_memstore/memstore_limit*100, 2) AS usage_pct FROM gv$memstore_info;如果usage_pct 90%立即扩容ALTER SYSTEM SET memstore_limit1.5G FOR TENANT test_tenant;注意memstore_limit不能超过memory_limit的50%否则OBServer启动失败。5.3 JMeter Aggregate Report里Error%为0但业务方说数据不对——检查obproxy.log里的routeOceanBase 2.2的OBProxy日志默认不记录SQL路由详情。你需要手动开启# 修改obproxy的etc/obproxy.conf enable_route_logtrue route_log_levelDEBUG然后重启OBProxy。再压测log/obproxy.log里会出现[2023-05-20 14:23:41.123] [DEBUG] [12345] route: tablet_user, part_id2, server192.168.1.11:2882如果发现part_id总是同一个比如永远是2说明分区键选择不合理数据倾斜了。这时要重跑ANALYZE TABLE t_user更新统计信息或者改分区策略为PARTITION BY RANGE COLUMNS(create_time)。5.4 Grafana里LS同步延迟突增——不是磁盘问题是net_thread_count不够当log_sync_time指标持续50ms第一反应是换SSD。但OceanBase 2.2的log_sync_time主要受RPC线程池影响。查当前配置SELECT * FROM gv$sysstat WHERE stat_name net_thread_count;默认是4。在2700并发下4个线程处理所有日志同步请求必然排队。解决方案不是加磁盘而是ALTER SYSTEM SET net_thread_count 8;这个参数热生效无需重启。改完后log_sync_time立刻回落到10ms以内。常见问题速查表现象可能原因快速验证命令解决方案JMeter连接超时OBProxyrs_list中某节点不可达curl http://127.0.0.1:2884/status检查对应OBServer的2882端口TPS卡在1200不上升MemStore使用率超90%SELECT * FROM gv$memstore_infoALTER SYSTEM SET memstore_limit响应时间波动大全局索引未走路由grep route: obproxy.log加enable_ob_routetrue跨租户事务失败日志盘使用率超阈值df -h /data/1/logALTER SYSTEM SET log_disk_utilization_threshold错误率100%但无报错OBServer内存OOM被killdmesg -Tgrep -i killed process6. 性能结论与教学价值延伸OceanBase 2.2在这次JMeter压测中展现出的不是纸面参数的堆砌而是一种“可验证的工程诚实”。它不回避自己的瓶颈点当LS同步成为瓶颈时它不伪装成IO问题而是通过log_sync_time指标直白告诉你当全局索引引发网络风暴时它不隐藏在TCP重传里而是用gv$session_wait的log file sync等待事件亮起红灯。这种透明性恰恰是教学环境中最珍贵的——学生不需要猜他们能看见每一行代码、每一个配置、每一次调整如何真实地改变系统行为。从实测数据看OceanBase 2.2在单租户场景下3000并发点查能达到1250 TPS平均延迟3.1ms二级索引扫描在1150 TPS时延迟9ms跨租户事务的极限是680 TPS。这些数字本身不重要重要的是它们背后的约束条件必须用oceanbase-client驱动、必须配OBProxy、必须调log_disk_utilization_threshold、必须开enable_ob_route。去掉任何一个性能就断崖下跌。这恰恰印证了分布式数据库的本质——它不是单机数据库的简单放大而是一套精密咬合的齿轮组少一颗螺丝整个系统就失准。对我个人而言这次压测最大的收获不是TPS数字而是确认了一个教学原则不要教学生“OceanBase有多快”而要教他们“OceanBase在什么条件下会变慢以及如何亲手把它调回来”。所以我在课程设计里把JMeter脚本拆解成12个可修改参数从Ramp-Up Period到log_disk_utilization_threshold让学生分组修改一个参数观察TPS曲线变化再用gv$视图验证猜想。当一个学生通过调大net_thread_count把log_sync_time从200ms压到10ms时他理解的不再是抽象概念而是“线程数”和“日志同步”之间真实的因果链条。最后分享一个小技巧OceanBase 2.2的gv$plan_cache_plan_explain视图能直接看到SQL执行计划的详细步骤和成本估算。在JMeter压测时我习惯在每轮测试后用这个视图对比不同并发下的执行计划是否变化。比如当TPS骤降时如果执行计划从TABLE GET变成了TABLE SCAN那问题一定出在统计信息过期或索引失效上而不是硬件瓶颈。这个技巧让我跳过了80%的无效排查直击核心。