全表更新太慢，数据量约65W

[五月]

可以参考我之前这个案例 数据库技术博客-OceanBase分布式数据库

[再练练手]

您好，这张表确实有触发器写入另外一张表，但是相同条件下，MySQL执行耗时不到1min，OB 20min都未结束。

[再练练手]

看了下，这张表有触发器会写入另一张表，但是去MySQL测试，也就1min不到写完了，OB 20min没有反应，这个场景是可以复现的。没有触发器的话，也是1min内更新完。

[shushushu]

学到就是赚到

[皇甫侯]

可以分别对比下有触发器和删除触发器的执行计划。。估计有变化

[再练练手]

变化非常大，没有触发器的30S左右就跑下来了，有触发器的 20min以上一直卡下去，还没有结束的感觉。。。

[皇甫侯]

我说是执行计划，可以用explain extended命令查看下

[再练练手]

有触发器：

无触发器：

[再练练手]

目前看，执行计划显示基本是一样的

[淇铭]

看着无触发器走的算子和有触发器走的算子不一样

1. DISTRIBUTED TABLE RANGE SCAN（分布式表范围扫描）：

分布式表范围扫描是指在分布式环境下，针对整个分布式表进行的范围扫描。在这种扫描方式下，OceanBase 会根据分区键将数据分布在多个节点上，并且在每个节点上执行范围扫描操作。这种方式可以充分利用集群的计算和存储资源，提高查询性能。

2. TABLE RANGE SCAN（表范围扫描）：

表范围扫描是指在一个单个的表上进行范围扫描。这种扫描方式通常用于非分布式环境或者只涉及到一个分区的数据查询。在这种情况下，查询只会在一个节点上执行。

你这个更新慢 应该和你触发器有关系

[再练练手]

噢噢，那老师目前的现象就是有触发器的走分布式表扫，太慢了，感觉时间上和单表扫也不是*3的关系（目前是1-1-1架构）， 分布式扫基本就是卡死走不动的样子

[淇铭]

@淇铭

• 首先推荐的当然是敏捷诊断工具，通过一键诊断分析对当前集群系统日志进行分析，快速发现可能得异常问题点，协助进行问题排查。可以按照小助手的提示排查
  日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”
• 全链路诊断中的Show Trace功能，也能轻松发现性能瓶颈并进行进一步的分析和调优。
• 以上两种方式可能并不是万能的，接下来可以按以下步骤尝试自查分析。
  a. 通过查看gv$ob_sql_audit审计视图确认影响执行耗时的等待事件。
  b. 再获取 SQL 执行计划EXPLAIN EXTENDED，查看执行计划并分析。
  c. 获取 sql plan monitor 信息，全过程可以参看如下操作。
  1.登录sys租户设置 sql_plan_monitor 参数

确认 sql_plan_monitor 已经打开

show parameters like ‘enable_sql_audit’;

如果 enable_sql_audit = False 则将其打开

alter system enable_sql_audit = true;
2. 登录业务租户，获取 sql 的执行计划
EXPLAIN EXTENDED sql语句;
3. 设置临时 trace 获取
SET ob_enable_show_trace=‘ON’;
4. 再次执行需要采集的 sql 语句
5. 获取上一步执行的 sql 的 trace_id 信息
select last_trace_id();
6. 临时关闭 plan monitor 数据，防止信息被覆盖
alter system enable_sql_audit = false;
7. 获取 plan monitor 的 sql ，将 xxxxx 替换为第 6 步返回的 trace_id ，以获取每个算子的吐行信息
select plan_line_id, plan_operation, sum(output_rows), sum(STARTS) rescan, min(first_refresh_time) open_time, max(last_refresh_time) close_time, min(first_change_time) first_row_time, max(last_change_time) last_row_eof_time, count(1) from oceanbase.gv$sql_plan_monitor where trace_id = ‘xxxxx’ group by plan_line_id, plan_operation order by plan_line_id;8 恢复 sql_audit 参数
alter system enable_sql_audit = true;
d.获取以上信息后，最好也提供对应 trace_id 信息的 observer.log 日志协助分析。

按照我上面发的 obdiag收集一下sql信息 具体看看

[再练练手]

好的 我收集下

[AntTech_PLSNIV]

能查询个gv$ob_SQL_AUDIT的记录吗，看下更新SQL的记录

[再练练手]

这个卡死跑不下去，SQL_AUDIT输不出来。。。

[再练练手]

复现：
1、create table t1(i int primary key,j int);

2、create table t2(i int);

3、CREATE trigger t1_update after update on t1

for each row

insert into t2 (i)

values (old.i);
4、插入t1表数据量约65W
5、update t1 set j=j+1;

[甯空]

SET _force_parallel_query_dop = 128;
SET _force_parallel_dml_dop = 128;
这两个参数试过吗？

[再练练手]

试过，没有什么效果

[再练练手]

问题已定位：
该版本触发器与事务的联动调度存在性能问题，同一个事务内循环调用PL时，savepoint的内存不会立即释放，事务处理与触发器调用就会越来越慢，从开始的微秒级别退化到毫秒甚至十毫秒级别，导致触发器长时间执行不完。后续版本会修复。