合并排序在数据库里怎么用才快点，效率提升那些事儿你得知道

说到数据库怎么跑得快,排序是个绕不开的大话题，你想啊，你查订单按时间倒序，查商品按价格从低到高，背后都是数据库在吭哧吭哧地排序，数据库用的排序方法里，合并排序是个顶梁柱，因为它稳定，不管数据多乱，它都能给你排得妥妥的，但怎么能让它更快点呢？这里面有不少门道。

你得明白数据库里的排序和内存里的排序不是一回事。

咱们在学校里学的合并排序,通常假设所有数据都能一股脑塞进电脑的内存里，但数据库要处理的数据量，动不动就是几个G甚至几个T，内存根本装不下，数据库用的是一种叫“外部归并排序”的变种，简单说，就是先把大数据切成一堆小块，每个小块用快排之类的算法在内存里排好序，变成一个个有序的“小文件”，然后再把这些“小文件”像合并扑克牌牌堆一样，一层一层地合并起来，最终得到一个完整的大有序文件，这个过程中，怎么处理这些“小块”和“合并”的步骤，就是提速的关键。

提速的第一招：让数据库有足够的内存（工作区）来干活。

根据数据库内部的优化机制（参考数据库查询优化器工作原理），它在进行排序操作前会先估算一下需要多少内存，如果它发现你要排序的数据量不大，估计内存能装下，它就会尝试一种更爽的方式：整个排序过程完全在内存里完成，避免读写硬盘那个慢吞吞的步骤，硬盘的速度和内存比起来，就像是自行车和高铁的区别，如果你的数据库服务器配置了足够大的内存，并且数据库的参数（比如Oracle的PGA，SQL Server的查询内存）设置得合理，让很多中小型的排序操作都能在内存里搞定，那速度的提升会是立竿见影的，这就好比给你一个大厨房，你就不用因为台面太小而频繁地把切好的菜先端到客厅再端回来了。

提速的第二招：巧妙地利用索引，让数据库“免排序”。

这是最厉害的一招,相当于釜底抽薪，如果数据库发现你要的排序结果，恰好某个索引已经帮它排好序了，它就会直接读取那个索引，按顺序把数据拿出来就行，根本不需要再启动复杂的合并排序流程，你经常要按“创建时间”倒序查订单，如果你在“创建时间”这个字段上建了一个索引，那么下次数据库执行这个查询时，就会像查字典一样，直接沿着索引树找到最早或最晚的记录，然后按顺序读下去，又快又省力，索引不是白建的，它会影响数据插入和更新的速度，所以得用在刀刃上，针对那些最常用、最影响性能的排序条件来建立。

提速的第三招：理解并优化“多路归并”的过程。

当数据量大到内存也装不下,必须进行外部归并排序时，合并的“路数”就很重要了，传统的合并排序是两两合并（二路归并），但数据库系统会更聪明，它会尝试一次性合并尽可能多的有序小文件，这就是“多路归并”，想象一下，你面前有8副已经按顺序理好的牌，如果两两合并，你需要合并7次，但如果数据库能一次性合并4副牌，那么只需要合并3次就行了，减少合并的趟数，就能显著减少读写硬盘的次数，而硬盘I/O通常是最大的性能瓶颈，数据库会根据自己的缓存大小，自动决定一次合并多少路最划算，我们能做的，依然是保证系统有足够的内存，为这种多路归并提供宽敞的“操作台”。

提速的第四招：避免不必要的排序和选择合适的数据类型。

排序慢是因为数据库做了“冤枉功”，你的SQL语句里包含了DISTINCT、GROUP BY或者某些JOIN操作，数据库可能为了完成这些操作，不得不先对数据进行排序，检查你的SQL，看看能不能通过优化查询逻辑来避免隐式的排序，排序的速度也和要排序的数据类型有关，对整数、短字符串排序，肯定比对长文本、或者复杂的自定义类型排序要快得多，在设计表结构的时候，如果某个字段需要频繁参与排序，尽量选择简单、紧凑的数据类型。

关注临时表空间的速度。

外部归并排序的过程中,会产生大量的临时文件，这些文件都写在数据库的临时表空间里，如果临时表空间所在的硬盘是速度很慢的机械硬盘，那么整个排序过程就会被硬盘的读写速度拖累，把临时表空间放在高速的SSD固态硬盘上，是提升大规模排序性能的一个非常有效的基础设施优化。

想让数据库里的合并排序快起来,核心思路就几点：加内存，减少对硬盘的依赖；建索引，从根本上避免排序；优化查询，别让数据库干多余的活儿；给数据库配上一双“快鞋”（SSD），理解了这些，你就能在设计和优化数据库时，更有针对性地提升那些排序操作的效率了。