可以从数据库层面尝试以下方法来解决此问题：

一、收集统计信息

1. 原因：

   • 数据库的统计信息对于优化器选择合适的执行计划至关重要。如果统计信息不准确或过时，优化器可能会做出错误的决策，例如选择全表扫描而不是索引扫描。

2. 操作步骤：

   • 使用 DBMS_STATS 包来收集相关表和索引的统计信息。
   • 例如，对于 T_BUSI_RUN 表：

     BEGIN
       DBMS_STATS.GATHER_TABLE_STATS(ownname => 'schema_name', tabname => 'T_BUSI_RUN');
     END;
     /
复制

• 同时也可以收集索引的统计信息：

     BEGIN
       DBMS_STATS.GATHER_INDEX_STATS(ownname => 'schema_name', indname => 'index_name_on_T_BUSI_RUN');
     END;
     /
复制

1. 注意事项：
   • 收集统计信息可能会消耗一定的系统资源和时间，因此最好在系统负载较低的时候进行操作。

二、检查索引是否可用和有效

1. 原因：

   • 索引可能因为各种原因变得不可用或无效，例如索引损坏、数据分布变化导致索引不再高效等。

2. 操作步骤：

   • 检查索引是否存在：

     SELECT index_name FROM all_indexes WHERE table_name = 'T_BUSI_RUN';
复制

• 确认索引是否有效：

     SELECT status FROM user_indexes WHERE index_name = 'index_name_on_T_BUSI_RUN';
复制

• 如果索引无效，可以尝试重建索引：

     ALTER INDEX index_name_on_T_BUSI_RUN REBUILD;
复制

1. 注意事项：
   • 重建索引会占用一定的时间和资源，并且在重建期间会锁定表，可能会影响其他正在进行的操作。

三、调整优化器参数

1. 原因：

   • 优化器参数可以影响优化器的决策行为。通过调整这些参数，可以引导优化器更倾向于选择索引扫描。

2. 操作步骤：

   • 例如，可以调整 OPTIMIZER_INDEX_COST_ADJ 参数，该参数用于调整索引访问成本的估算。较小的值会使优化器更倾向于选择索引扫描。

收起

sql

复制

     ALTER SESSION SET OPTIMIZER_INDEX_COST_ADJ = n; -- n 是一个合适的数值，通常在 1 到 100 之间
复制

• 还可以调整其他相关的优化器参数，如 OPTIMIZER_MODE（选择优化器的模式，如 ALL_ROWS、FIRST_ROWS 等）。

1. 注意事项：
   • 调整优化器参数需要谨慎，因为不正确的参数设置可能会导致其他性能问题或错误的执行计划。在调整参数之前，最好了解每个参数的含义和影响，并在测试环境中进行充分的测试。

把where改成and的这个改写是不等价的;

原SQL的right join实际上是inner join, 而将where改写成and后, right join仍然是outer join.   后者的结果集理论上要>=前者的结果集;

有可能迁移前后两库的参数配置不一样. 建议对该SQL迁移前后的库各采集sqlhc信息进行分析.

原SQL将righ join改成inner join是没问题的, 因为这个right join本身就是一个inner join的逻辑,  但是为什么优化器没有使用正确的执行计划, 根据现有的信息, 还是看不出来.