就前一篇中的例子, 来作一下10046的跟踪, 看看排序倒底占据了多少的CPU. 我一直是认为就算几条记录的排序也是有代价的, 至少它需要去准备一块排序区, 并运行排序的算法. 有时数据库系统中每秒种会有上千次的内存排序, 这时如果将排序的次数减少到一半, 机器的负荷会下降多少呢? 对于排序没有直接的印象, 不象对于逻辑读那么熟悉. 就等着一步一步研究吧?
先来看一下分区列上用绑定变量(有排序)时的情况:
SELECT * FROM TEST_SORT
WHERE COL2=:p_co1 AND PKEY=:p_key AND COL1 IN (810,510,210)
ORDER BY COL1
Rows Row Source Operation
------- ---------------------------------------------------
3 SORT ORDER BY (cr=9 r=0 w=0 time=390 us)
3 PARTITION ... (cr=9 r=0 w=0 time=246 us)
3 INLIST ITERATOR (cr=9 r=0 w=0 time=240 us)
3 TABLE ACCESS BY ... (cr=9 r=0 w=0 time=205 us)
3 INDEX RANGE SCAN ... (cr=6 r=0 w=0 time=141 us)
然后来看一下分区列中不用绑定变量(无排序)的情况:
SELECT * FROM TEST_SORT
WHERE COL2=:p_co1 AND PKEY=0 AND COL1 IN (810,510,210)
ORDER BY COL1
Rows Row Source Operation
------- ---------------------------------------------------
3 INLIST ITERATOR (cr=10 r=0 w=0 time=253 us)
3 TABLE ACCESS BY ... (cr=10 r=0 w=0 time=211 us)
3 INDEX RANGE SCAN ... (cr=7 r=0 w=0 time=152 us)
可以看到如果没有排序时, 时间基本相等(246 us和253 us), 有了排序后就上升到了390 us, 虽然这个排序什么也没有做, 因为返回的记录已经排好序了. 在这儿就三条记录, 但CPU时间上升了50%. 因此在OLTP中减少不必要的排序是很有必要的.
留言 (5)
optimizer_features_enable设为9.2.0以上时就是没有排序的, 在这儿搞乱大家了, sorry!
Posted by anysql | Aug 21, 2006 11:44 AM
我在9205上试还是要排序的, 汪海在9207上试是不需要排序的.
Posted by anysql | Aug 21, 2006 12:58 PM
我也在9207上试了, 是不需要排序的, 看来应当和optimizer_features_enable参数无关.
Posted by anysql | Aug 21, 2006 2:01 PM
嘿嘿,下一个话题又引到如何减少排序了
Posted by boypoo | Aug 21, 2006 5:16 PM
原来是Bug (ID: 3823191), Unnecessary sort when access made through a local index.
Posted by anysql | Aug 23, 2006 10:56 AM