咱们一步步拆解为啥加了ORDER BY之后你的customer表查询性能直接从15秒飙到5分钟以上，结合这类用户表的常见坑，还有你手里的EXPLAIN和Profile信息来捋清楚：

1. 排序操作没用到索引，被迫触发全结果集内存/磁盘排序 #

如果你的ORDER BY字段（或多字段组合）没有对应的覆盖索引，也没有能匹配排序顺序的前缀索引，数据库根本没法直接从索引里拿到现成的有序数据——只能先把所有符合WHERE条件的结果全部捞出来，再额外做一次排序操作。

• 先看EXPLAIN的Extra列：要是出现Using filesort，那实锤了！这意味着数据库得先在内存里排序，内存不够就写到磁盘临时文件里继续排。要是你的查询结果集有几十万甚至上百万条，磁盘IO的速度可比内存慢几十上百倍，时间直接拉爆太正常了。
• 对比原查询：原来没加ORDER BY的时候，数据库可能直接按过滤索引捞数据返回，根本不需要额外排序，所以15秒就能搞定；加了排序后，光是排序这一步在Profile里可能占了90%以上的耗时。

2. ORDER BY强制放大了结果集，打破了原查询的优化逻辑 #

有时候原查询可能用到了LIMIT或者高效过滤逻辑，数据库可以提前终止扫描（比如用索引快速找到前N条符合条件的数据），但加了ORDER BY之后，数据库必须先把所有符合WHERE条件的数据都找出来、排好序，才能取前N条——这会让原本只需要扫描几千条数据的查询，变成扫描全表几百万条。

• 看EXPLAIN里的rows字段：原查询的rows数值可能很小，加了ORDER BY后rows直接暴涨到全表行数，这就是最明显的信号。
• 举个例子：原查询是SELECT * FROM customer WHERE country='US' LIMIT 100，能通过country索引快速揪出100条；但加了ORDER BY create_time后，数据库得先把所有美国客户都查出来，排序完再取100条，结果集瞬间放大N倍。

3. 排序内存不足，触发磁盘临时表 #

数据库的排序内存（比如MySQL的sort_buffer_size）是有限的，如果结果集大小超过了这个阈值，就会把数据写到磁盘的临时表里做排序，磁盘IO的速度和内存根本不在一个量级，时间自然就上去了。

• 从Profile里看：如果有Creating tmp table或者Copying to tmp table on disk的步骤，而且耗时极长，那就是这个问题没跑了。
• 原查询不需要排序，所以不会用到这么多临时内存/磁盘资源，加了ORDER BY后直接触发了这个瓶颈。

4. ORDER BY干扰了索引选择，导致执行计划恶化 #

有时候ORDER BY会让数据库放弃原本高效的过滤索引，转而选择一个能支持排序的索引，但这个索引的过滤效率极低——相当于捡了芝麻丢了西瓜。

• 比如原查询用customer_id索引快速过滤，但加了ORDER BY create_time后，数据库可能选择create_time索引，但这个索引没法快速匹配WHERE条件，结果变成全表扫描后再排序，耗时直接拉满。
• 对比EXPLAIN的type和key字段：原查询的type是range或ref（高效的索引扫描），key是对应的过滤索引；加了ORDER BY后type变成ALL（全表扫描），key变成了排序相关索引或者NULL。

• 先盯死EXPLAIN的Extra列：如果有Using filesort，优先给ORDER BY字段结合WHERE条件建联合索引，比如WHERE country='US' ORDER BY create_time就建(country, create_time)的联合索引，这样数据库能直接从索引里拿到有序结果，完全不需要额外排序。
• 看Profile的耗时分布：哪个阶段占比最高？如果是Sorting result，那就是排序开销太大；如果是Sending data，那得先优化WHERE条件缩小结果集。
• 对比两次查询的EXPLAIN：重点看rows、key、type的变化，确认是不是索引选错了或者结果集被放大了。

内容的提问来源于stack exchange，提问作者Victor Company