一：问题现象
T_XXX 表同步延时 1 小时，其它表同步速度正常 ；
主要慢在同步时的一个 delete T_XXX 语句上，单条执行耗时 12 秒；
二：问题原因
T_XXX 表存在唯一性索引，理论上速度很快；
查看 T_XXX 表存在 delete 行级触发器，查看触发器逻辑，发现触发器内一个 update 语句特别慢；
UPDATE CHENJCH.T_CHENJCH_RISK ..where RISK_ID ....
查看执行计划， update 语句走全表扫描，速度很慢，通过 hint 强制走主键索引，速度特别快；
为什么执行计划不走主键？
查看 T_CHENJCH_RISK 表统计信息显示表有 0 行数据，但是实际上有 200 万行数据；
由于数据同步时 T_CHENJCH_RISK 表存在大量的 delete/update/insert 操作，上次收集统计信息时正好这个表里没有数据，但是经过几天的数据同步后，表里的数据量发生了很大变化，统计信息也不是实时进行收集，最终导致生成较差的执行计划；
三：解决方案
尝试删除 T_CHENJCH_RISK 表统计信息，让数据库通过动态取样实时的收据信息，但是执行计划没有变，还是走全表扫描，速度没有提高；
begin
dbms_stats.delete_table_stats(ownname => 'CHENJCH', tabname => 'T_CHENJCH_RISK');
end;尝试重新收集 T_CHENJCH_RISK 表统计信息，让数据库通过动态取样实时的收据信息，但是执行计划没有变，还是走全表扫描，速度没有提高；
begin
DBMS_STATS.GATHER_TABLE_STATS('CHENJCH',
'T_CHENJCH_RISK',
estimate_percent => 100,
method_opt => 'FOR ALL INDEXED COLUMNS',
degree => 6,
CASCADE => TRUE);
end;为什么执行计划没有变？
(数据库版本 Oracle 12.2.0.1.0)
因为 SQL 语句存在绑定变量， SQL 文本没有变，导致执行计划也没有发生变化；
通过对表 T_CHENJCH_RISK 添加和删除注释，可以让数据库重新生成执行计划；
comment on column CHENJCH.T_CHENJCH_RISK.RISK_ID is 'PK_T_CHENJCH_RISK';
comment on column CHENJCH.T_CHENJCH_RISK.RISK_ID is '';查看新生成的执行计划， T_CHENJCH_RISK 已经开始走主键索引了，速度有明显提升；
转载自chenoracle
