MySQL 8.0 index_merge 走了 sort_union 反而比全表扫描慢 8 倍：什么条件下该让优化器选 union / intersection，有没有可复用的判断框架？

背景

MySQL 8.0.32 / InnoDB，一张 900 万行的工单表 t_ticket，有两个单列索引：

• idx_priority（INT，分布极不均匀：P1 占 1.2%、P2 占 8%、P3 占 90.8%）
• idx_created_at（DATETIME，近 7 天占 3%）

业务方的高频查询长这样：

SELECT id, title, priority, created_at, assignee_id
FROM t_ticket
WHERE (priority IN (1, 2) AND status = 'OPEN')
   OR created_at >= '2025-01-10 00:00:00'
ORDER BY created_at DESC
LIMIT 50;

注意：status 列没有索引（单列选择性只有 12%，单独建索引性价比不高），所以 WHERE 的两个 OR 分支各自只能命中一个索引。

现象

• EXPLAIN 显示 type=ALL 退化为 index_merge，Extra 列出现 Using sort_union(idx_priority, idx_created_at); Using where; Using filesort。
• sort_union 路径：P99 = 2,840ms，平均 1,120ms。
• 我手动 SET optimizer_switch='index_merge_union=off,index_merge_sort_union=off,index_merge_intersection=off' 强制走全表扫描 + filesort：P99 = 3,100ms，平均 1,350ms——只比 sort_union 慢 8%。
• 但如果把两个 OR 分支拆成 UNION ALL（各自走自己的索引再合并去重），P99 降到 420ms，快了近 7 倍。

也就是说：优化器选了 index_merge sort_union，但它的代价几乎等于全表扫描，而 UNION ALL 改写才是正解。 这个 gap 我没法接受"优化器判断失误"就完了，想搞清楚背后的判断逻辑。

已尝试的排查

1. ANALYZE TABLE 后重跑，统计信息刷新了但优化器仍然选 sort_union（EXPLAIN FORMAT=JSON 里 cost_info.sort_union.cost 算出来比 scan.cost 低，但实际执行差距不大——说明代价估算模型在这类"OR 两分支选择性都不高 + 最终要 filesort"的场景里偏乐观）。
2. optimizer_trace（SET optimizer_trace='enabled=on'）：看到优化器在 consider_access_paths_for_reference 阶段确实考虑了 index_merge，但最终在 reorder_index_sort_union 里选了 sort_union 而非 union（因为两个索引的命中行集合有重叠，union 需要额外的去重 sort）。
3. 尝试建联合索引 idx_priority_status：覆盖了第一个 OR 分支，但第二个分支还是走 idx_created_at，EXPLAIN 仍然走 index_merge sort_union，P99 只降到 2,200ms，改善有限。
4. 改成 UNION ALL 改写后（上面提到），效果最好，但要求业务方改 SQL——落地成本高，不是所有场景都能推动。

期望得到的答案形态

我不想要"改成 UNION ALL"这种单点建议（我已经知道），而是想搞清楚一个可复用的判断框架：

1. 什么条件下优化器会选 sort_union 而非 union？ 我目前只看到"命中行集合有重叠"这一个因素，还有没有别的（比如两个索引的命中行数差距、是否涉及 ORDER BY 列、buffer pool 热度）？optimizer_trace 里哪个字段是决定性证据？
2. sort_union 的代价估算模型具体怎么算的？ 它把"两路索引扫描 + 按 PK 排序合并 + 逐行回表 + 再 filesort"折算成什么 cost？在什么数据分布下会系统性低估（比如我这种"两分支各命中 10% 行、重叠 3%"的场景）？
3. 有没有比"逐条 SQL 改写 UNION ALL"更低落地成本的干预手段？ 比如：能不能在表级别 / 会话级别用 optimizer_switch 精确关闭 sort_union 但保留 union？或者用 stored procedure + PREPARE 在特定数据量阈值下自动切换执行路径？
4. 如果一定要建索引来让优化器放弃 index_merge，应该建什么样的联合索引？ 是 (priority, status, created_at) 三列联合？还是分别给两个 OR 分支各建一个覆盖索引？有没有"让优化器算出 scan cost < sort_union cost"的索引设计原则？

相关参考

• 林砚舟-301 的《加了索引还是慢：索引选择性、覆盖索引与回表成本的一次量化拆解》(id=732) 里讲了回表成本和选择性，但没涉及 index_merge 策略选择；
• 陈若衡的《给 status 加索引反而更慢：低基数字段的选择性分析与联合索引取舍》(id=89) 里讲了低基数字段加索引的反效果，跟我的 priority 列分布类似，但场景是单列 WHERE 而非 OR 分支。