单条 INSERT 平均 RT 超过 10ms 问题分析

问题现象

客户业务从 MySQL 迁移至 OceanBase 后，发现单条 INSERT 语句的平均响应时间超过 10ms。目标表为分区表，包含两个 MEDIUMTEXT 字段。SQL Audit 显示 execute_time 和 queue_time 均较长，但 CPU 负载不高，可排除 CPU 瓶颈。

问题原因

客户在插入数据时，虽然表结构中将 id 列定义为自增列（AUTO_INCREMENT），但实际插入操作并未使用数据库的自增机制。应用程序框架使用雪花算法生成 id 值，并手动指定给 id 列。由于手动指定的 id 值跳跃幅度较大，超出了系统参数 auto_increment_cache_size 定义的缓存大小，导致每次插入都需要访问内部表以获取或同步自增序列值，从而增加了 INSERT 操作的性能开销。

关键信息

1. 性能分析：
   • OAS（OceanBase 自治服务）监控显示，SQL 执行耗时中排队时间占比较高。
   • 分析指定 sql_id 的 ASH（Active Session History），top foreground db time 事件指向与自增序列相关的内部操作。
2. 表结构：
   目标表 engine_process_track_14 的主键 id 列为自增列，且 AUTO_INCREMENT_MODE 设置为 'ORDER'。

CREATE TABLE `engine_process_track_14` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  -- ... 其他列定义
  PRIMARY KEY (`id`),
  -- ... 索引定义
) AUTO_INCREMENT_MODE = 'ORDER' ...;

3. 问题根因：
   • 实际插入的 id 值由雪花算法生成，与数据库维护的自增序列无关。
   • 观察到的连续两次 INSERT 操作，其手动指定的 id 值差值（848,926,433,279）远大于系统参数 auto_increment_cache_size 的值（1,000,000）。
   • 当手动插入的 id 值超过当前缓存范围时，OceanBase 需要访问内部表来调整自增序列的全局状态，这个同步操作引入了额外的性能损耗，表现为 queue_time 和 execute_time 的增加。

问题的风险及影响

• 性能下降：单条 INSERT 语句的响应时间显著增加，直接影响业务的写入性能。
• 并发瓶颈：在高并发写入场景下，此问题可能被放大，导致系统吞吐量下降，影响用户体验。

适用版本

全部 OceanBase 版本。

解决方法

协调应用研发团队修改代码逻辑，在插入数据时，对于定义为 AUTO_INCREMENT 的列，不要手动赋值，而是交由数据库自动生成。确保应用层充分利用数据库的自增列功能。

规避方式

• 设计阶段：在设计表结构时，若决定使用自增列，应在应用设计规范中明确禁止对该列进行手动赋值。
• 代码审查：对于已上线的应用，建议进行代码审查，识别并修正所有对自增列进行手动赋值的 INSERT 操作，确保其遵循数据库设计规范。