ORDER BY本身不直接导致JOIN内存溢出，但与JOIN共存且缺索引或执行计划失准时，数据库会全量载入JOIN结果再排序，从而吃光内存；必须为ORDER BY字段建索引、避免视图内固化排序、优先分批查询而非调大内存参数。
ORDER BY 本身不直接导致 JOIN 内存溢出，但当它和 JOIN 共存、且缺少索引或执行计划失准时，数据库会把“全量 JOIN 结果”先载入内存再排序——这才是真正吃光内存的元凶。
ORDER BY 字段没索引时，MySQL 会强制全量排序
只要 EXPLAIN 显示 Extra 列含 Using filesort，且 rows 值接近表总行数，就说明 MySQL 正在把整个 JOIN 后的结果集捞进内存（或磁盘临时表）做排序。此时调大 sort_buffer_size 只是延缓崩溃：256KB 不够 → 改成 8MB → 还是不够 → 最终 Out of sort memory 或直接断连。
- 复合排序更危险：比如
ORDER BY status, created_at DESC，必须建联合索引(status, created_at)才能避免全量排序 - 视图里定义了
ORDER BY？外层再加LIMIT很可能无效——MySQL/PG 都不一定下推，结果仍是全排再截断 -
MyISAM表完全不使用sort_buffer_size，排序强制走磁盘临时表，性能和内存压力双崩
JOIN + ORDER BY 组合让优化器放弃索引路径
即使 JOIN 字段本身有索引，ORDER BY 字段缺失索引也会让执行计划退化：优化器发现无法用索引完成排序，就放弃利用 JOIN 索引的归并路径（如 MERGE JOIN），转而选择先把所有匹配行取出，再统一排序。这时 type 可能从 ref 降为 ALL，Extra 出现 Using join buffer (Block Nested Loop) + Using filesort —— 内存双重吃紧。
- SQL Server 中，
ORDER BY字段类型不一致（如INTvsBIGINT）会触发隐式转换，导致JOIN索引失效，优化器被迫选HASH JOIN+ 全量排序 - PostgreSQL 的
work_mem会同时为HASH JOIN和SORT各分配一份，一条语句可能消耗 2–3 倍配置值 - MySQL 8.0.22+ 默认启用
HASH JOIN，但join_buffer_size已基本失效；sort_buffer_size仍管排序，却不管哈希构建
分批查比调参更能绕过这个组合陷阱
与其在 sort_buffer_size、tmp_table_size、work_mem 之间反复试探，不如拆掉“JOIN + ORDER BY”这个高危组合：先按主键范围分片取左表 ID，再用这些 ID 精准拉右表数据，最后在应用层或子查询中控制排序与截断。
- 左表需有单调主键（如
id BIGINT PRIMARY KEY），右表关联字段（如user_id）必须有索引 - 批次大小建议从 5000 起步，避免
IN列表过长触发max_allowed_packet限制 - 不要在应用层拼超长
IN (1,2,3,...,20000)字符串；Java 用PreparedStatement批量绑定，Python 用executemany() - PostgreSQL 可改用
VALUES构造临时集合：WHERE o.user_id IN (SELECT id FROM (VALUES (1),(2),...,(2000)) AS v(id))
真正卡住的从来不是语法，而是执行路径是否可控。一旦 EXPLAIN 里出现 Using temporary 或 Using filesort 且 rows 高企，说明数据库已经在内存里堆数据了——这时候优先建索引、拆查询，比改任何内存参数都快、都稳。
