Navicat中UNION ALL查询只显示第一个分支执行计划，因MySQL原生命令仅对首个SELECT生成执行计划；须手动拆解各分支加EXPLAIN分析，并注意统计信息更新、字段别名、导出格式及UNION/UNION ALL语义区别。
UNION ALL查询在Navicat中为什么总只显示第一个分支的执行计划？
因为Navicat的EXPLAIN功能底层调用的是MySQL原生命令，而MySQL对含UNION ALL的语句仅对第一个SELECT子句生成执行计划——其余分支完全不参与分析。这不是Navicat的bug，是MySQL server层的行为限制。
常见错误现象：你在视图里写了5个UNION ALL分支，Navicat的“解释”按钮点开后只看到第一个分支走索引，后面4个实际全表扫描却毫无提示，导致线上慢查询排查失败。
- 必须手动拆解：把整个
UNION ALL语句复制出来，逐个运行每个SELECT子句前加EXPLAIN FORMAT=TRADITIONAL - 注意统计信息同步：拆解后某一分支显示“Using index”，但线上仍慢，大概率是该表的
ANALYZE TABLE没更新过 - 避免依赖Navicat“视图展开”功能：右键视图→“查看数据”再点“解释”，结果仍是第一个分支；必须用原始SQL重写
如何用Navicat 16安全地调试多分支UNION ALL查询？
直接运行完整UNION ALL语句容易掩盖单个分支的性能问题，尤其当某个分支返回百万行、其他分支只返回几行时，Navicat默认加载全部结果会卡死或内存溢出。
- 分段执行：用
Ctrl + Shift + R（运行选中语句）精准执行单个SELECT分支，观察执行时间与行数 - 加
LIMIT 100临时限制：在每个分支末尾手动加LIMIT 100，确认逻辑正确后再去掉 - 禁用“自动提交”：在连接属性中关闭
Auto-commit，防止误执行INSERT/UPDATE类分支 - 字段对齐检查：确保所有分支的列数、类型、顺序一致，否则Navicat报错
ERROR 1222 (21000): The used SELECT statements have a different number of columns
导出UNION ALL结果集时为什么Excel里数据错位？
Navicat导出时若未显式指定字段别名，同名字段（如多个分支都有id）会被合并为一列，导致父子关系断裂——这是最隐蔽也最常被忽略的问题。
- 必须显式命名：每个分支的公共字段都加别名，例如
SELECT id AS user_id, name FROM users和SELECT id AS order_id, amount FROM orders - 禁用
*：哪怕结构一致也禁止用SELECT *，Navicat导出CSV时列顺序可能因MySQL版本差异变动 - 导出格式选
.xlsx：CSV无类型推断，日期字段易变文本，且中文默认ANSI编码乱码；.xlsx能保留数字/日期格式 - 大数据量分页导出：单次结果超5万行时，在SQL里加
LIMIT和OFFSET，用脚本循环调用navicat.exe /exportCLI命令
UNION ALL vs UNION：什么时候必须用ALL？
UNION ALL不是“可选优化”，而是语义必需——去掉ALL会触发隐式去重排序，性能暴跌且结果不可控。
- 典型误用场景：用
UNION合并日志表（log_202608,log_202609），本意是拼接，结果MySQL对千万级数据做DISTINCT + filesort，耗时从0.2秒涨到47秒 - 唯一可用
UNION的情况：你明确需要去重，且已确认重复行有业务意义（如合并用户注册来源，需过滤重复手机号） - 验证方法：对同一语句分别跑
SELECT COUNT(*)和SELECT COUNT(DISTINCT *)，若两者接近，说明UNION带来的开销几乎白付
EXPLAIN结果与线上行为不一致。别迷信工具界面里的“执行计划”，它永远只是快照。 
