屏幕底端显示了该任务分析的 SQL 语句的 SQL ID。SQL ID 前面的小箭头显示了这些 SQL 语句是改进了还是退化了，SQL ID 后面的数字显示了改进或退化的百分比。这些数据告诉您更改对每条 SQL 语句的确切影响。如果您愿意，可以通过单击 SQL ID 查看相应的 SQL。注意第一条 SQL，它受到的影响最大，如果单击该 SQL，您会看到与下面类似的屏幕：

这个屏幕显示了有关执行该 SQL 的大量统计信息。 屏幕底部显示了执行计划的比较：

现在您可以看到，使用索引是如何强制减少缓冲区的。但是，情况总是那么乐观吗？看看另一条 SQL：

与上一例的 31.95% 相比，此例改进甚微，只有 0.48%。原因是什么？为了找到答案，单击 SQL ID，出现如下屏幕：

在这里，您可以看到究竟是什么改变了。所用时间实际上从 0.504 秒延长为 1.022 秒，而且都是因为 CPU 时间。为什么？如果您检查一下数据分布模式，您就会看到 promo_id 是这样分布的：

SQL> select promo_id, count(1) cnt from sales group by promo_id;
PROMO_ID        CNT
---------- ----------
534          1
999     887837
350      18022
33       2074
351      10910
----------
sum            918844

promo_id 999 在表中出现了 887,837 次，将近 97%。当将计划改为包含索引扫描时，这个查询就比较困难了。如果对全表进行扫描，情况应该会好一些。因此，即使整体影响是积极的，也会有个别组件拖后腿。当您决定是否要更改参数时，您应该考虑到这些 SQL 语句的重要性，这些语句既可能改进也可能退化。

正如您所见，您希望评估对数据库参数进行重要更改而带来的影响。使用 SPA，您不必估计潜在的性能影响，连“猜测估计”也不必。您可以使用应用程序针对数据库执行的 SQL 语句客观地衡量。

现在看另一个案例：更改参数后，性能退化了，而不是改进了。下面是一个屏幕截图：

这里，SQL 语句的运行情况都比更改之前要差。您可以利用（本文中讨论的）SQL 计划管理解决这个问题。SPM 允许您选择优良的执行计划作为您的基准，从而保证执行计划的稳定性。随后，优化程序会将这个基准用于相应 SQL 的所有执行过程。这个基准计划会一直使用，直到被禁用或者您创建了新的基准计划。另一个解决 SQL 退化问题的方法是使用 SQL Tuning Advisor，它能提出 SQL 调整建议或建议进行外部修改，如通过创建索引提高性能。