同一Oracle数据库同schema下两表查询速度差异巨大的原因是什么

Oracle数据库端问题 #

• 索引配置差异：你执行的查询包含order by col1逻辑，如果Table1的col1列未创建索引，Oracle需要对全表数据做磁盘排序后再返回，开销远高于Table2（如果Table2的col1是主键/建有索引，可直接按索引有序返回，无需额外排序）。
• 存储结构异常：Table1可能存在大量行迁移、行链接，或者高水位线（HWM）异常偏高：比如历史上有过大量删除操作未做表重建，全表扫描时需要扫描大量无数据的空块，实际IO效率极低。
• 实际数据量差异：即使列数、行数一致，Table1的col2/col22字段可能为CLOB、BLOB等大字段类型，或者单条记录平均长度远高于Table2，实际需要读取的总数据量是Table2的上百倍。
• 执行计划异常：Table1的统计信息过时，Oracle优化器生成了错误的执行计划，比如走了不必要的全表扫描、嵌套循环关联，而Table2的执行计划符合预期。
• 并发与锁冲突：同步运行时Table1可能存在未提交的长事务持有排他锁/行锁，查询需要频繁访问undo段做一致性读，拖慢读取速度。
• 资源限制差异：查询账号可能被配置了Oracle Profile规则，限制了访问Table1时的CPU、IO使用上限，访问Table2时无相关限制。

Pentaho ETL配置问题 #

• 拉取批次配置差异：两个表的输入步骤fetch size配置不一致：Table1的fetch size可能设置为10，每次仅从Oracle拉取10行数据，而Table2的fetch size设置为1000，批次拉取效率更高。
• 隐式转换逻辑差异：即使查询语句一致，Table1的字段可能在Pentaho中配置了额外的转换规则（比如编码转换、格式校验、自定义脚本处理），单条数据处理开销远高于Table2。

目标端SQL Server问题 #

• 速率统计异常可能是写入瓶颈导致的：Table1写入目标库时，目标表存在大量索引、触发器、外键约束，需要实时校验和更新索引，写入阻塞会被统计为读取速率低；而Table2同步时提前禁用了约束和索引，写入速度快，看起来读取效率更高。

内容的提问来源于stack exchange，提问作者Abhinavneni