开发学院数据库 DB2 神秘的 DB2 排序阅读

神秘的 DB2 排序

　2009-11-16 00:00:00　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�

闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕濡ょ姷鍋涢ˇ鐢稿极閹剧粯鍋愰柟缁樺笧閳ь剦鍙冨鍝勑ч崶褏浠奸梺璇茬箲閼归箖鎮鹃悜钘夎摕闁靛濡囬崢鐢告⒑鐟欏嫷鍟忛柛鐘崇墵閵嗗倹绺介崨濠勫幈闁硅壈鎻槐鏇熺墡闂備線娼уú銈団偓姘嵆閻涱噣骞掑Δ鈧粻锝嗙節闂堟稑鏆欏ù婊堢畺閺岋綁濮€閳惰泛婀辨竟鏇熺節濮橆厾鍘甸梺缁樺姦閸撴岸鎮樻潏銊ょ箚闁圭粯甯炴晶娑氱磼缂佹ḿ娲寸€规洖宕灃闁告劕鍟犻崜婵堟崲濞戞ḿ鏆嗗┑鐘辫兌閺佹牜绱撴担浠嬪摵闁圭懓娲ら悾鐑藉箳閹搭厽鍍甸梺鐟板悁閻掞箓鎮楅幖浣光拻濞达絿鍎ら崵鈧梺鎼炲€栭悧鐘荤嵁韫囨稒鏅搁柨鐕傛嫹

婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繑銇勯幘鍗炵仼缂佺媭鍨堕弻娑㈠箛闂堟稒鐏堥悗鐟版啞缁诲啴濡甸崟顖氱閻庨潧鎽滈悾濂告⒑绾拋娼愭繛鑼枎椤繒绱掑Ο鑲╂嚌闂侀€炲苯澧畝锝堝劵椤︽煡鎮￠妶澶嬬厪闁割偅绻冮崑顏呯箾瀹割喕绨婚幆鐔兼⒑鐎圭姵銆冮柤鍐茬埣瀹曟繈鏁冮埀顒勨€旈崘顔嘉ч柛鈩冾殘閻熸劙姊洪悡搴℃毐闁绘牕銈稿畷鐑樼節閸パ冨祮闂侀潧楠忕槐鏇㈠储椤忓牊鈷戦柟鑲╁仜閸旀鏌￠崨顔锯姇缂佸倹甯熼ˇ瀵哥磼鏉堛劌绗氭繛鐓庣箻閸┾剝鎷呴柨瀣垫綗闂傚倷娴囧銊╂倿閿曞倸绠查柛銉墮閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柣鎴ｅГ閸ゅ嫰鏌ら崫銉︽毄濞寸姵姘ㄧ槐鎾诲磼濞嗘帒鍘＄紓渚囧櫘閸ㄥ爼濡撮崘顔煎窛闁哄鍨归崢娲倵楠炲灝鍔氭い锔诲灦瀹曪繝骞庨懞銉у帾闂婎偄娲﹀ú鏍ㄧ墡闂備浇顕х€垫帡宕滈悢濂夋綎闁惧繐婀辩壕鍏间繆椤栨碍鎯堟い顐㈢焸濮婃椽宕烽娑欏珱闂佺ǹ顑呭Λ婵嬪箚閳ь剚銇勮箛鎾寸ォ婵☆垰瀚板娲传閸曨剚鎷卞┑鐐插级宀ｅ潡骞戦姀鐘斀濠电姴瀚弶鎼佹⒑閸濆嫭宸濆┑顔惧厴閹即濡烽埡鍌楁嫽婵炶揪绲介幖顐ゆ暜鐠轰警鐔嗛柣鐔峰簻閺€鑽ょ磼閸屾氨孝妤楊亙鍗冲畷鐓庮潩閿濆懍澹曢梺鍝勫暙閻楀棛绮堥崘鈹夸簻闊洤娴烽ˇ锕€霉濠婂牏鐣洪柡灞诲妼閳规垿宕卞☉鎵佸亾濡も偓椤儻顧侀柛鐘崇墵濠€渚€姊虹紒妯曟垿鎮烽妷褉鍋撳鐓庢灓缂侇喚绮妶锝夊礃閳哄啫骞堟俊鐐€栭崝鎴﹀磹閺囥垹鍑犻幖娣妽閻撶喖鐓崶褜鍎忛柛鏃€绮撻弻鏇㈠炊瑜嶉顓犫偓娈垮枟濞兼瑨鐏掗梺鍛婄箓鐎氼剝顤傛繝纰夌磿閸嬫垿宕愰幋锕€鍨傛繛宸簼閸嬶繝鏌嶉崫鍕櫣缂佺姵鐗犻弻宥夊煛娴ｅ憡娈查梺绋挎捣閸犳牠寮婚弴銏犵倞鐟滃秶鑺辨繝姘厵闁告垯鍊栫€氾拷

核心提示： 对于示例中的 SQL，DB2 依次评估每个索引，神秘的 DB2 排序(3)，我们来看看 DB2 可以考虑采用的众多访问路径中的四种：如果使用第一个索引，DB2 可以匹配 lastname、以传统方式使用此索引并按照索引次序获取表行，这种方式在获取表页面之前执行一次 RID 排序，解释了最后一个神

对于示例中的 SQL，DB2 依次评估每个索引。我们来看看 DB2 可以考虑采用的众多访问路径中的四种：

如果使用第一个索引，DB2 可以匹配 lastname、以传统方式使用此索引并按照索引次序获取表行。在读取表行时，对每一行应用 workdept 上的谓词。对于符合条件的每一行，DB2 获取 lastname、workdept 和 jobcode 。不需要执行排序。但是，如果表不是按照 lastname 次序排列的，读取会是随机和同步的。

如果使用第一个索引，DB2 可以匹配 lastname 并以另一种非传统的列表预抓取方式使用此索引。 DB2 读取索引并找出 lastname 大于或等于主机变量的所有索引指针 (RID) 。然后，DB2 按照 RID 次序对这些 RID 排序（也就是按照表页面次序和 ID 映射项次序）。获得有序的 RID 列表之后，DB2 可以使用此列表连续获取表页面 / 行，异步地把页面预抓取到缓冲区池中。通过使用有序的 RID 列表，DB2 找到预抓取的页面上的每个表行，应用 workdept 上的谓词，如果表行满足 lastname 谓词和 jobcode 谓词，就获取选择的三列。因为其中的 RID 排序会打乱索引次序，所以需要执行数据排序以满足 ORDER BY lastname 子句的要求。

如果使用第二个索引，DB2 可以匹配两列（workdept 和 lastname）。由于与两列进行匹配，DB2 读取的表行更少（只包括同时满足两个谓词的表行）。对于读取的每个表行，DB2 获取 workdept、lastname 和 jobcode 。需要按照 lastname 次序对符合条件的行排序。

如果使用第三个索引，DB2 不能匹配任何谓词，但是可以通过检查 lastname 和 workdept 对索引数据应用谓词。对于每个符合条件的索引行，DB2 可以从索引本身获取所选的三列，因此避免读取表。另外，因为此索引的第一列是 lastname，数据会按照 lastname 次序返回。不需要排序。

这个神秘现象的本质

如果有 ORDER BY 子句，DB2 会尝试避免排序（并不保证一定避免排序，但是它会考虑这一因素）。上面的访问路径 1 和 4 使 DB2 能够在不执行排序的情况下以所需的次序获得符合条件的行。

如果删除 ORDER BY 子句，DB2 就不会尝试避免排序。其他因素就变得更重要了，比如避免同步读取。访问路径 2 和 3（但不包括最后的数据排序）就变得更有吸引力了。

通过考虑访问路径 1 和 2，就可以理解添加 ORDER BY 子句为什么可能消除排序，而删除 ORDER BY 可能会导致排序。如果添加 ORDER BY 子句，DB2 可能倾向于选择访问路径 1，不执行排序；如果删除 ORDER BY，DB2 可能选用不执行最后数据排序的访问路径 2 。但是，访问路径 2 包含另一个排序，即 RID 排序。因此，删除 ORDER BY 子句实际上可能在访问路径中引入排序。

尽管在访问路径 1 和 2 中 DB2 选择的索引是相同的，但是 ORDER BY 子句导致 DB2 以传统方式使用索引，从而避免排序。删除 ORDER BY 子句导致 DB2 以列表预抓取方式使用索引，这种方式在获取表页面之前执行一次 RID 排序。

解释了最后一个神秘现象

现在，我们已经解释了 DB2 中的另一个神秘现象。

上一页 1 2 3