同一mysql实例跨库join必须显式写全库名.字段名，否则报错；跨实例需federated引擎或中间件，不支持原生join；字符集、类型不一致会导致索引失效。
同一 MySQL 实例下跨库关联，直接用 db1.table1 和 db2.table2 语法就能跑通，但字段名不加库前缀必报错；跨实例则不能直接 JOIN，得靠 FEDERATED 引擎或中间件——别指望一条 SQL 全搞定。
同一实例跨库 JOIN 必须显式写全库名.字段名
MySQL 不会自动推断字段来自哪个库，哪怕你用了表别名。漏掉库前缀是新手最常踩的坑，比如 ON users.id = orders.user_id 会直接报 Unknown column 'users.id' in 'on clause'。
-
ON子句里所有参与关联的字段，只要跨库，就必须带库名：写成ON db1.users.id = db2.orders.user_id - 即使两个表在同一个库，也建议统一加上库名（如
db1.users.id），避免后续把表迁到别的库时 SQL 突然失效 - 如果字段名在多个库中都存在（比如都有
id），不加库前缀就触发歧义，优化器无法生成执行计划 - 别依赖
USE db_name切库来简化写法——它只影响默认数据库，对跨库 JOIN 无作用
FEDERATED 引擎是跨实例查询的唯一原生方案
MySQL 本身不支持跨实例的 JOIN，FEDERATED 是唯一内建的远程表映射机制，但它不是“开箱即用”：引擎默认常被禁用，且结构必须完全一致。
- 先确认是否启用：
SHOW ENGINES;查看FEDERATED行的Support是否为YES；若为NO，需在my.cnf加federated并重启 - 本地建表语句的字段定义、类型、索引必须和远程表**逐字节一致**，否则查不到数据或报错
-
CONNECTION字符串里的密码是明文存储的，任何能执行SHOW CREATE TABLE的用户都能看到 - 远程表增删改不会触发本地事务，也无法加锁，
SELECT可能读到不一致快照
跨库视图能封装逻辑，但权限和迁移风险极高
用视图包装跨库查询看似干净，实际埋了三个雷：权限检查滞后、运行时报错不可预知、无法跨实例迁移。
- 创建视图时只校验语法，不校验表是否存在；等真正
SELECT视图时，才抛Table 'db2.orders' doesn't exist - 视图定义里强制要求写全
db1.users这种形式，不能省略库名 - 视图依赖的库如果被删、重命名或迁到另一台机器，视图立刻失效，且没有任何预警机制
- 备份恢复后，目标实例若没有同名库+同结构表，视图查出来全是空或报错，上线前必须手动验证
字符集不一致会让索引彻底失效
两个库用不同字符集（比如 utf8mb4_0900_as_cs vs utf8mb4_general_ci），JOIN 时 MySQL 会隐式转换字段类型，导致无法走索引——执行计划里会出现 Using where; Using join buffer。
- 用
SHOW CREATE DATABASE db1;和SHOW CREATE DATABASE db2;对比字符集与排序规则 - 关联字段类型最好也保持一致：一个用
VARCHAR(64)，另一个别用CHAR(64)，否则也可能触发隐式转换 - EXPLAIN 结果里如果
key列为空，且Extra出现Using join buffer，八成是字符集或类型不匹配
跨库关联最危险的不是写不出 SQL，而是误以为它和单库 JOIN 一样可靠——事务原子性、锁范围、执行计划稳定性，全都不在一个量级上。线上用之前，务必在真实数据量下跑一遍 EXPLAIN，并验证异常路径（比如某个库临时不可用）下的行为。
