db2嵌套查询效率_DB2数据库SQL优化方法一列

OPTIMIZE FOR 子句声明只想检索部分结果或者优先检索前几行,优化器可以选择能够将检索前几行所需的响应时间缩至最短的访问方案。此外，作为单个块发送到客户机的行数由 n 的值限制。因此，OPTIMIZE FOR 子句既影响服务器从数据库检索合格行的方式，又影响将那些行返回给客户机的方式.

例如，假定您定期查询 EMPLOYEE 表以确定哪些职员的薪水最高：

select lastname, firstnme, empno, salary     from employee     order by salary desc

虽然您先前已对 SALARY 列定义了一个降序索引，但因为职员按职员编号排序，所以此索引的集群度可能不佳。为了尽量避免许多随机的同步 I/O，优化器将可能选择列表预取访问方法，此方法要求对所有合格行的行标识进行排序。此排序可能会导致在将前几个合格行返回给应用程序之前发生延迟。为了防止此延迟，请在语句中添加 OPTIMIZE FOR 子句，如下所示：

select lastname, firstnme, empno, salary     from employee     order by salary desc     optimize for 20 rows

在这种情况下，优化器可能选择直接使用 SALARY 索引，这是因为只检索薪水最高的 20 位职员。无论可以对多少行进行分块，都只将包含 20 行的行块返回给客户机。

使用 OPTIMIZE FOR 子句，优化器优先选择能够避免大批操作或流中断(例如排序操作所引起的情况)的访问方案。您最有可能使用 OPTIMIZE FOR 1 ROW 子句来影响访问路径。使用此子句有下列作用：

降低了连接序列包含组合内表的可能性，这是因为它们需要临时表。

连接方法可能会有所更改。最有可能的选项是嵌套循环连接，这是因为它的开销成本较低，并且在检索少量行时通常更有效率。

1.更有可能存在与 ORDER BY 子句匹配的索引，这是因为 ORDER BY 不要求进行排序。

2.降低了列表预取的可能性，这是因为此访问方法要求进行排序。

3.降低了顺序预取的可能性，这是因为只需要少量的几行。

4.在连接查询中，有可能将包含 ORDER BY 子句中的列的表选作外表，前提是该外表的某个索引提供了 ORDER BY 子句所需的排序。

虽然 OPTIMIZE FOR 子句适用于所有优化级别，但它在优化类 3 和更高优化类下工作得最好，这是因为低于 3 的优化类使用宽限连接枚举搜索策略。此方法有时会产生无法使它们自己快速检索前几行的多表连接访问方案。如果已打包的应用程序使用调用级接口(DB2 CLI 或 ODBC)，那么可以在 db2cli.ini 配置文件中使用 OPTIMIZEFORNROWS 关键字，让 DB2 CLI 在每个查询语句的末尾自动追加 OPTIMIZE FOR 子句。

从昵称选择数据时，结果可能随数据源支持的不同而有所变化。如果昵称所引用的数据源支持 OPTIMIZE FOR 子句，并且 DB2 优化器将整个查询下推至数据源，那么将在发送到数据源的远程 SQL 中生成该子句。如果数据源不支持此子句，或者优化器确定最低成本方案是本地执行，那么将在本地应用 OPTIMIZE FOR 子句。在这种情况下，DB2 优化器将优先选择能够最大程度缩短检索某个查询前几行的响应时间的访问方案，但可供优化器用于生成方案的选项略微受限，并且 OPTIMIZE FOR 子句对性能的改善幅度可能微不足道。

如果同时指定 OPTIMIZE FOR 子句和 FETCH FIRST 子句，那么两个 n 值中的较小者将影响通信缓冲区大小。为了进行优化，这两个值被视为互不相关。

FETCH FIRST n ROWS ONLY 子句

FETCH FIRST n ROWS ONLY 子句设置可检索的最大行数。将结果表限制为只包含前几行有助于提高性能。无论结果集可能另外包含多少行，也只检索 n 行。

如果同时指定 FETCH FIRST 子句和 OPTIMIZE FOR 子句，那么两个 n 值中的较小者将影响通信缓冲区大小。为了进行优化，这两个值被视为互不相关。

阅读(1839) | 评论(0) | 转发(0) |