Merge Join触发高CPU主因是隐式排序：当输入数据未按连接键有序时，优化器强制插入Sort节点。确认方法包括EXPLAIN中出现Sort上游节点、Using filesort或Sort Method: external merge；规避需同时满足连接字段有方向一致的索引、WHERE不破坏最左前缀、字段类型严格一致。
为什么Merge Join会触发高CPU排序
Merge Join本身不直接排序，但它要求两个输入数据流都已按连接键有序。如果数据库无法从索引或物化结果中直接获得有序数据，就会在执行前主动插入Sort节点——这才是CPU飙升的真正源头。常见于：ORDER BY字段与JOIN字段重叠、WHERE条件未命中有序索引、或优化器误判数据已排序。
如何确认Merge Join正在做隐式排序
运行EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+），重点看以下信号：
-
Sort节点出现在Merge Join上游，且Actual Total Time占比高 - Extra列出现
Using temporary; Using filesort（MySQL） - 计划中显示
Merge Join但Rows Removed by Filter远高于Rows Read，说明排序后大量行被丢弃 - PostgreSQL中
Sort Method: external merge表示已落盘，必然拉高CPU和I/O
避免Merge Join排序的3个硬性条件
不是加个索引就能跳过排序，必须同时满足：
- 两张表的连接字段上，各自存在**方向一致、顺序严格匹配**的索引，例如
ON t1.a = t2.b，则t1需有INDEX(a)，t2需有INDEX(b)；若写ORDER BY t1.a, t2.b，索引还必须是INDEX(a, b)联合索引（仅当两字段同属一张表时才有效） - WHERE条件不能破坏索引的最左前缀，比如t2有
INDEX(status, created_at)，但查询是WHERE created_at > '2025-01-01'，则created_at无法利用该索引的有序性 - 连接字段类型必须完全一致，
INTvsBIGINT、VARCHAR(50)vsVARCHAR(100)都可能触发隐式转换，导致索引失效、排序 fallback
比Merge Join更轻量的替代方案
当排序成本不可控时，主动引导优化器避开Merge Join：
- 对小表（/*+ USE_NL(t1 t2) */（Oracle）或
STRAIGHT_JOIN（MySQL）强制Nested Loop，避免排序开销 - 等值连接且内存充足时，加
/*+ USE_HASH(t1 t2) */提示走Hash Join——它不依赖输入有序，只消耗哈希计算CPU，通常比外部归并排序更稳 - 若业务允许，把
ORDER BY移到应用层：先取ID列表，再分批查详情，彻底剥离排序对数据库的压力
排序不是必须由数据库完成的环节，尤其当关联后结果集已远小于原始表时，把排序逻辑外移反而更可控。最容易被忽略的是：即使你没写ORDER BY，GROUP BY、DISTINCT、窗口函数也会悄悄引入排序——检查执行计划时别只盯JOIN节点。
