insert into select 使用上旁路导入比不使用执行时间变慢了2.4倍

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】v4.3.5.0
【问题描述】insert into … select … 语句使用上旁路导入比不使用性能下降了 50%，求问原因
【复现路径】问题出现前后相关操作

  1. 部署集群，选用 OLAP 场景创建租户
obd cluster tenant create obtest -n test --max-cpu=28 --memory-size=98G --zone-list=zone1,zone2,zone3 --primary-zone=RANDOM \
--locality=F@zone1,F@zone2,F@zone3 --charset=utf8 -s 'ob_tcp_invited_nodes="%"' --optimize=olap
  1. 调整配置参数
set global parallel_servers_target = 560; 
ALTER SYSTEM SET default_table_store_format = 'row';
SET GLOBAL parallel_degree_policy = MANUAL;
  1. 用 sysbench 准备3个表数据，每个表1000万行
  2. create table tmp1 like sbtest1;
  3. ALTER TABLE tmp1 MODIFY id int(11) NOT NULL; – 删除目标表主键自增属性
  4. 分别使用旁路导入和传统路径导入插入数据，发现使用旁路导入执行时间变慢了2.4倍。
mysql> insert /*+ enable_parallel_dml parallel(16) no_direct */ into tmp1 select * from sbtest1;
Query OK, 10000000 rows affected (10.24 sec)
Records: 10000000  Duplicates: 0  Warnings: 0

mysql> truncate table tmp1;
Query OK, 0 rows affected (0.16 sec)

mysql> insert /*+ enable_parallel_dml parallel(16) DIRECT(true, 0, 'full') */ into tmp1 select * from sbtest1;
Query OK, 10000000 rows affected (24.42 sec)
Records: 10000000  Duplicates: 0  Warnings: 0
  1. 用上 NO_GATHER_OPTIMIZER_STATISTICS hint 没有区别
mysql> insert /*+ enable_parallel_dml parallel(16) DIRECT(true, 0, 'full') NO_GATHER_OPTIMIZER_STATISTICS */ into tmp1 select * from sbtest1;
Query OK, 10000000 rows affected (24.58 sec)
Records: 10000000  Duplicates: 0  Warnings: 0

mysql>  insert /*+ enable_parallel_dml parallel(16) no_direct NO_GATHER_OPTIMIZER_STATISTICS */ into tmp1 select * from sbtest1;
Query OK, 10000000 rows affected (10.45 sec)
Records: 10000000  Duplicate:: 0  Warnings: 0

执行计划：

@论坛小助手

#3

推荐使用 obdiag 工具进行日志采集，以便我们分析性能下降的原因。

日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

请将采集到的日志提供给我们，以便确认问题所在。另外，为了更好地帮助您定位问题，请您提供以下信息：

  1. 旁路导入开启前后，具体的执行计划是否有变化？
  2. 是否有其他系统资源（如CPU、内存、IO）使用率的变化？
  3. 数据量和数据分布在这两次测试中是否完全一致？
  4. 是否存在锁等待或者阻塞的情况？

这些信息将有助于我们更准确地分析性能下降的原因。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

可以按照小助手的提示
SQL性能收集一下
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”