神秘的 DB2 排序

在其他许多情况下，这个索引也有助于避免排序。

DB2 的思考方式

假设我们定义了一个索引，在执行包含适当的 ORDER BY 子句的 SQL 时，DB2 可以使用它避免排序。再假设还有其他索引可供选择。那么，DB2 为什么会选择一个索引，而不选择另一个呢？有许多原因：

SQL 语句中有排序语法而且索引之一可以避免排序。

有一个或多个 WHERE 子句谓词，DB2 可以对此索引应用这些谓词，从不符合条件的行中过滤出符合条件的行。

选择的所有列和 WHERE 子句中提到的所有列（实际上，就是 SQL 语句中任何地方提到的所有列）都包含在此索引中。 DB2 可以执行只索引访问，完全避免读取表。

在一个索引中级别数量是 4 ；在另一个索引中是 2 。

一个索引的次序与表数据相同，而其他索引不是。

SQL 语句中有 OPTIMIZE FOR 1 ROW 。

其他许多原因。

同时存在以上多个原因。

当 DB2 为 SQL 选择访问路径时，它会衡量使用不同索引的好处，并考虑根本不使用任何索引（表空间扫描）。

SQL 选项

现在看看当 DB2 评估前面给出的一个 SQL 语句时会发生什么：

　Select　workdept,　lastname,　jobcode　
　from　employee_master　
　Where　workdept　in　('A01',　'B22',　'B46')　
　And　lastname　>=　:hvlastname　
　Order　by　lastname　

DB2 可以使用三个索引之一获取表行：

lastname、firstname 和 middle_initial 上的 Index1

workdept 和 lastname 上的 Index2

jobcode、workdept 和 lastname 上的 Index3

DB2 根据 I/O、CPU 和排序开销计算使用每个索引的成本。它会估计对索引和对表的 Get Pages 操作数量。通过检查基数（cardinality）统计数据，估计在应用和匹配索引谓词之后可能有多少个索引 RID 符合条件。检查索引的深度和广度。计算在一个索引页面上有多少索引行，以及在一个表页面上有多少表行。按照与表次序的关系评估索引次序。它还要考虑其他许多东西，尤其是 SQL 的语法。选择了哪些列？哪些 WHERE 子句条件可以应用于索引？哪些必须应用于表数据？用户是否关心数据的次序？是否可以只使用索引获取所有数据，而不必读取表数据？