是，跨库查询的explain会失效，因mysql不支持跨库统计信息合并，仅查当前库索引，导致key为空、rows失真，甚至误标all；必须在语句主库下执行explain，且需结合慢日志或performance_schema验证真实耗时与扫描行数。
跨库查询的 explain 会失效吗？
会，而且非常容易误判。navicat 点击「解释」按钮时，实际执行的是 explain select，而跨库语法（如 db1.users join db2.orders）会让 mysql 优化器无法准确估算各表的关联代价，导致 key 列为空、rows 严重失真，甚至把本该走索引的步骤标成 all。
根本原因不是 Navicat 的问题，而是 MySQL 的 EXPLAIN 本身不支持跨库统计信息合并——它只查当前连接默认库的 information_schema.STATISTICS，对其他库的索引一无所知。
- 务必在目标语句所属的「主库」下执行
EXPLAIN，比如语句以db1.开头，就先右键切换到db1连接再点解释 - 避免用
USE db1;+ 跨库查询的方式触发解释，Navicat 可能仍按当前连接上下文解析，而非语句中显式指定的库 - MySQL 8.0+ 默认返回
FORMAT=tree，Navicat 解析可能截断关键字段；手动改写为EXPLAIN FORMAT=TRADITIONAL SELECT ...更稳妥
怎么拿到真实执行耗时与扫描行数？
跨库查询不能只信 EXPLAIN 的预估，必须看真实执行数据。但 EXPLAIN ANALYZE 在 MySQL 不可用，得换招：
- 对 MySQL/MariaDB：把原语句包装成子查询，再套一层
SELECT SQL_NO_CACHE ...，并开启慢日志（long_query_time = 0），然后在 Navicat 的「查询分析器」里筛选出这条语句，看rows_examined和实际耗时 - 确认 MariaDB 的
performance_schema已启用（SHOW VARIABLES LIKE 'performance_schema'返回ON），Navicat for MariaDB 17.0+ 的「可视化解释」能从events_statements_summary_by_digest中提取该跨库语句模板的真实平均rows_examined和avg_timer_wait - PostgreSQL 用户注意：
EXPLAIN ANALYZE支持跨库（Foreign Data Wrapper），但 Navicat 调用时若提示权限错误，需检查pg_hba.conf是否允许本地连接执行SHOWPLAN
为什么「查询分析器」里找不到你的跨库语句？
Navicat 的「查询分析器」默认只采集慢日志或 performance_schema 中已归一化的语句摘要，而跨库语句常因库名字面值不同被拆成多个 digest，比如 SELECT * FROM db_a.t1 JOIN db_b.t2 和 SELECT * FROM db_x.t1 JOIN db_y.t2 在 digest_text 中是两条记录，不会合并。
- 临时解决：在「查询分析器」源选择里切到「General Query Log」，但需提前在服务端打开
general_log = ON（仅调试，不可长期开启） - 更可靠的做法：直接在 MySQL 命令行执行
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%JOIN%db_%' ORDER BY AVG_TIMER_WAIT DESC LIMIT 5;，再把结果粘进 Navicat 分析 - 如果语句含变量（如
WHERE id = ?），确保 Navicat 执行时没启用手动参数绑定，否则?可能被替换为具体值，破坏 digest 归一化
跨库 JOIN 的性能陷阱在哪？
真正卡住的往往不是语法，而是数据搬运。MySQL 执行跨库 JOIN 时，会先把驱动表的数据拉到 server 层，再逐行去另一库查匹配行——相当于嵌套循环，网络延迟和单行查询开销会被放大。
- 检查执行计划中是否出现
Using join buffer (Block Nested Loop)：这是 MySQL 在硬扛，说明没走索引下推，且 buffer 不够大会频繁刷盘 - 对比单库等价查询的
rows：如果跨库版rows比单库版高一个数量级，基本可判定是驱动表选择错误或缺少跨库统计信息 - MariaDB 用户可尝试加
/*+ MAX_EXECUTION_TIME(5000) */提示，防止某次跨库查询拖垮整个连接池
跨库查询的性能分析，核心不是看 Navicat 界面里那张表格，而是确认「它到底从哪读的数字」——慢日志、performance_schema 还是 general_log，来源不同，结论可能完全相反。
