排序变慢的核心原因是数据库需额外计算和资源重排数据，尤其在数据量大、内存不足或缺乏有效索引时性能显著下降；常见瓶颈包括磁盘排序、缺失匹配索引、复杂排序表达式及并发锁竞争。
排序变慢，核心原因是数据库需要额外计算和资源来重新组织数据行的物理或逻辑顺序，尤其当数据量大、内存不足或缺乏有效索引时，性能下降会非常明显。
数据量超出内存（SORT_AREA_SIZE / work_mem 不足）
数据库执行 ORDER BY 时，通常先尝试在内存中完成排序。如果结果集太大，超出了分配给排序操作的内存（如 Oracle 的 SORT_AREA_SIZE，PostgreSQL 的 work_mem，MySQL 的 sort_buffer_size），就会把中间结果写入磁盘临时文件。磁盘 I/O 远慢于内存访问，这是排序突然变慢最常见的原因。
- 检查当前会话或全局的排序内存配置是否合理
- 对单次大排序可临时调高（如 PostgreSQL 中
SET LOCAL work_mem = '256MB'），但需避免过度占用导致并发性能下降 - 监控是否出现磁盘排序：PostgreSQL 查
EXPLAIN ANALYZE中的 “Disk:” 提示；Oracle 查v$sesstat中 “sorts (disk)” 计数
缺少匹配的索引
如果没有能覆盖排序字段的索引，数据库只能先取出所有满足 WHERE 条件的行，再整体排序。即使只取前 10 行（LIMIT 10），也可能要先排序全部百万行才能知道哪 10 行排最前。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 为常用排序字段建立索引，例如
CREATE INDEX idx_user_age_desc ON users(age DESC) - 复合索引要注意字段顺序：
WHERE status = 'active' ORDER BY created_at DESC适合建(status, created_at DESC)索引 - 注意索引是否被真正使用：用
EXPLAIN确认执行计划里出现了 Index Scan using … 而非 Sort + Seq Scan
排序字段类型或表达式复杂
对函数结果排序（如 ORDER BY UPPER(name)）、多字段组合（尤其是含 NULL 或不同方向）、或使用非常规类型（如 JSON 字段提取后排序），都会增加 CPU 开销，并可能使索引失效。
- 尽量避免在 ORDER BY 中用函数，可改用函数索引（如 PostgreSQL 的
CREATE INDEX idx_upper_name ON users(UPPER(name))） - 混合 ASC/DESC 排序时，确保索引定义与查询一致，否则可能无法利用索引避免排序
- 对文本字段排序要注意字符集和排序规则（collation），某些 collation 比较代价高，甚至强制转成 Unicode 再比
并发与锁竞争加剧延迟
在高并发场景下，大量排序请求争抢内存、CPU 或临时表空间，也可能触发操作系统级调度延迟。此外，若排序涉及正在被更新的表（尤其未提交事务持有行锁），还可能因等待锁而卡住。
- 观察系统负载：CPU 使用率是否持续 100%？I/O 等待是否升高？
- 检查长事务或未提交操作，它们可能阻塞其他查询的排序准备阶段
- 考虑将耗时排序操作移到低峰期，或用物化视图/汇总表预计算排序结果
排序不是天然慢，而是资源、设计和语句写法共同作用的结果。找准瓶颈点——是缺内存、没索引、还是逻辑太重——就能针对性优化，而不是盲目加机器或调参数。
