简单陈述一下:
针对每个session,排序首先会使用sort_area_size ,如果不足则会使用临时表空间。但这里面又到底是怎么一个过程呢?下面阐述一下,也许对大家有用处(如果有什么不清楚或者不恰当的地方欢迎大家探讨)
假设sort_area_size = 100k,正好能盛下100条记录进行排序
当排序记录小于等于100条,ok,所有排序在内存中进行,很快
但若超过100条,则会使用临时表空间(利用磁盘进行)
我们选取一个临界值来说明,假设需要排序的记录有10010条
这个时候我们进行的排序会分为101组进行
每读100条进行一次小组排序,然后写入磁盘,第101组只有10条,排序后也写入磁盘
这是进行第二次排序,这次排序将在前100小组里面各抽取一条进行排序。《按照我个人的猜测,应该是排好后每写入一条入磁盘则将该记录所在小组重新抽取一条出来进行排序(这时是有序记录组里面所以很快)》。当这个过程完成后,这时所需要的磁盘空间大约为 实际记录存储空间的2倍(这也是多数书上提到的排序空间大约是记录空间的2倍的原因)
由于还剩下10条记录,于是这10条记录需要跟前面排序的10000条记录进行排序合并,这个代价也是相当大的!
所以,我们通常推荐,假如你需要排序的记录最大为100万条,则sort_area_size最小要能装下1000条,否则如上面的例子,那多余的10条,仅仅10条将会带来巨大的代价!
如果,设置的极度不合理的情况下,排序记录达到了 sort_area_size所能容纳的三次方以上,比如上面例子中排序需要100万记录
那么同样的,重复这个过程,当每一万条记录如上排序后,再如上从这100小组(每组10000条记录)各抽一条进行排序……
在这个过程中,磁��的消耗和时间的代价大家都应该有个感性认识了
所以,我们建议: sprt_area_size 所能容纳记录数至少大于排序记录数的 平方根
除了下面这点个人猜测外,其他的都是这样的
《按照我个人的猜测,应该是排好后每写入一条入磁盘则将该记录所在小组重新抽取一条出来进行排序(这时是有序记录组里面所以很快)》。
之所以这样猜测是因为个人觉得这样的方式效率能比较高并且算法简单容易控制,资源消耗也少
大家可参考内容
http://www.ixora.com.au/q+a/space.htm#end
If my table occupies 500M of disk space, and I have a 1M sort_area_size, how much temporary tablespace disk space do I need to perform the following sorts?
1. select col1, col2, col3 from tablename order by col1, col2, col3;
2. select col1, col2, col3 from tablename order by col1, col2;
The sort space requirements are dependent on the size of the row source being sorted, rather than the size of the key. Your two sorts would require the same amount of disk space. However, if you were joining to another table and including one of its columns in the select list, then the size of the row source to be sorted could be larger than the largest base table.
It is also possible for the disk space requirements to be up to twice the size of the row source if the sort area size is too small. If for example you need to sort 1,001,000 rows and your sort area size can only accommodate 1000 rows at a time. Then the first phase of the sort will be to read the row source, and write 1001 sort runs of 1000 rows each to the temporary segment. The next phase is to read one row at a time from each of the first 1000 sort runs and merge them into a single large sort run. Towards the end of this phase, you need space for all the original 1001 sort runs and the big sort run at the same time - which is nearly twice the row source size. The third phase of this sort would be a second merge pass to merge to large sort run with the remaining original 1000 row sort run. To avoid this, and process a sort in a single merge pass, the sort area size must hold at least as many rows as the square root of the number of rows in the row source.