在最新版 DB2 for z/OS 中，我们关于 ORDER BY
的知识体系必须更新。不仅仅是有新内容需要学习，而且我们以前了解的 ORDER BY 也发生了许多变化。我将在以后几期中探讨这些引人深思的、甚至令人不安的问题其中的 5 个：- 一个分区数据二级索引（data-partitioned secondary index，DPSI）结构对 ORDER BY
排序规避的影响。
使用 “random” 索引选项对 ORDER BY 排序规避的影响在您的 SQL 语句中，只有一个 GROUP BY COL1, COL2 VS 既有 GROUP BY COL1, COL2 后续还有（不必要？） ORDER BY COL1,COL2 的问题使用 DYNAMIC SCROLL 光标作为一个强迫 DB2 避免 ORDER BY（或者任何其他索引可用于避免排序的语法）排序的新方法的可能性使用 UPDATE WHERE CURRENT OF 光标的新（有限）功能，即使在 CURSOR 声明中有一个 ORDER BY — 这就是说，光标是一个 “明确地只读光标”排序规避的一些背景知识
很久以前，在我 Programmers Only 专栏的一篇文章（“Looking for a little ORDER ”）中，我解释过 DB2 不能在 OPEN CURSOR
中为所有符合条件的行自动生成一个结果集。如果您有一个长期运行的 OPEN CURSOR，并不是因为 DB2 正在构建一个结果集，最有可能是因为 DB2 正在 OPEN（通常满足一个常见 ORDER BY）上进行数据排序。我不介意员工说 DB2 在排序的时候在 OPEN CURSOR 上建立了一个 SORTOUT 文件。为什么？因为很明确，这项工作的结果是排序。如果员工说 DB2 在 OPEN 上建立了一个结果集，我会提出异议，因为称其为 “结果集” 暗示着它总是 为每个 OPEN 而构建，而没有说明结果集实际上是一个 SORTOUT 文件，其创建和必要性都是语法和访问路径驱动。这不是给定的，也不是必需的。记住，排序语法，比如 ORDER BY
，并不一定要引起数据排序。有了适当的访问路径（可用一个索引，正确使用该索引，DB2 可以将符合条件的行以预期的次序返回到您的程序），即使没有排序 ORDER 需求也会得到满足。事实上，使用一个索引来避免排序的一个关键方法是提高 SQL 性能，使其比应用 FETCH 实际获取的行更多。如果 DB2 不需要排序，那么所有寻找一个符合条件的行（或者有多行 FETCH 的行）的工作在每个 FETCH 中就可以完成。如果您停止了 FETCH 查询，那么 DB2 将停止寻找符合条件的行。您只需支付查询您实际需要行的费用。现在，我所说的以正确 方法使用适当 索引的意思是什么呢？一个适当的索引允许 DB2 在不使用排序的情况下以您想要的次序检索您想要的行。例如，如果您在 LASTNAME
、FIRSTNAME、MIDINIT 和 EMPID（都是升序）上有一个 “4 列” 索引，您可以编写如下 SQL 语句：| SELECT … FROM BIGTABLE
WHERE LASTNAME = :HVLASTNAME |
接着是下述 ORDER BY
的子句：| ORDER BY FIRSTNAME, MIDINIT, EMPID
ORDER BY FIRSTNAME, MIDINIT
ORDER BY FIRSTNAME
ORDER BY FIRSTNAME DESC, MIDINIT DESC, EMPID DESC
ORDER BY FIRSTNAME DESC, MIDINIT DESC
ORDER BY FIRSTNAME DESC
|
然后，DB2 可以以 “传统” 方法（索引、表、索引、表，等等）使用这个 “4 列” 索引以期望的次序（与索引相同或相反的顺序）返回所需行。如果 DB2 以非传统方法（LIST PREFETCH
方法）使用索引，这些行可能不能以索引次序返回，而是以表中的次序返回。那就是说，如果表最近被使用 REORG 重组，这些行可能以表 CLUSTER 次序返回，（中间维护或 “日志应用” 不会对完美的次序有影响）。如果 DB2 没有一个适当次序的索引可以避免排序，或者当 DB2 以 LIST PREFETCH
方法使用任何索引时，那么一个 ORDER BY 必定会引起数据排序。因此，现在就到了之前提到的 5 个新问题了。
问题 1：DPSI 结构对排序的影响
创建一个 DPSI，您基本上会采取原本单个有序列表（以前是不分区索引 [NPI] ，现在重命名为未分区二级索引 [NPSI]）所采取的方法，使用行标识符指针指向一个表空间的所有分区，然后将其转换为多个有序列表。指针每次只指向其中一个分区。因为我们的主题索引与我们的表次序（不是我们的 CLUSTER
索引）不相同，一个 NPSI 的次序对于整个 表来说可能是随机的，而一个 DPSI 的每个索引分区的次序可能只是对于自己的分区 来说是随机的，而且（我们喜欢这样的）有可能会成为一个更窄（子页更少）、更短（层级更少）的索引。当我们从单个分区访问行时，这些都是特别好的特性。我们不是很乐意使用 DPSI，但是我们必须跨多个分区探测多个索引树来寻找行。如果我们使这个索引成为我们的 CLUSTER 索引，作为一个 NPSI，这个索引仍然对于整个表（在 LASTNAME 上分区）来说是随机的，但是作为一个 DPSI，每个索引分区可能要与其表分区保持一致（不是随机的）。再一次重申，当您从单个分区上访问行时，这是一个非常好的特性，当然，这是理想的情况。使用一个 DSPI 来访问多个分区不太理想的话，从 SQL 性能的角度来说可能非常棘手。稍后详解。图 1 显示了两个索引的一个示例：一个是 DPSI ，另一个是 NPSI ，在列 ZIPCODE
上。表在图的中间。表中的列有EMPID、LASTNAME、HIREDATE 和 ZIPCODE。表目前是在 LASTNAME 上进行 CLUSTER 操作。
图 1. 在列 ZIPCODE 上的 DPSI 和 NPSI 索引示例
