1) 我要检查的第一件事是数据库参数在 Prod 和 Dev 之间是否相同。如果影响基于成本的优化器决策的参数之一不同,则所有赌注都将取消。您可以在 v$parameter 视图中看到参数;
2)拥有最新的对象统计信息很棒,但请记住您指出的巨大差异 - Dev 拥有 10% 的 Prod 行。此行数被考虑到 CBO 如何决定执行查询的最佳方式。鉴于行数的巨大差异,我不希望计划是相同的。
根据具体情况,优化器可能会选择对具有 20,000 行 (Dev) 的表进行全表扫描,它可能会决定索引在具有 200,000 行 (Prod) 的表上的成本较低。(数字仅用于演示,CBO 使用成本计算算法来确定 FTS 和索引扫描的内容,而不是绝对值)。
3) 系统统计数据也纳入解释计划。这是一组代表 CPU 和磁盘 i/o 特征的统计数据。如果您在两个系统上的硬件不同,那么我希望您的系统统计信息会有所不同,这可能会影响计划。来自 Jonathan Lewis 的一些很好的讨论在这里
您可以通过 sys.aux_stats$ 视图查看系统统计信息。
现在我不确定为什么不同的计划对你来说是一件坏事......如果统计数据是最新的并且参数设置正确,那么无论大小差异如何,你都应该从任一系统获得不错的性能......
但是可以从您的 Prod 系统中导出统计数据并将它们加载到您的 Dev 系统中。这使您的 Prod 统计信息可用于您的开发数据库。
检查 DBMS_STATS 包的 Oracle 文档,特别是 EXPORT_SCHEMA_STATS、EXPORT_SYSTEM_STATS、IMPORT_SCHEMA_STATS、IMPORT_SYSTEM_STATS 过程。请记住,您可能需要在 10g/11g 上禁用晚上 10 点的夜间统计作业......或者您可以在导入后调查锁定统计信息,以便它们不会被夜间作业更新。