MySQL支持同一实例下的跨库JOIN，需用db_name.table_name前缀并确保用户具备双库SELECT权限；跨实例则不支持直接JOIN，须通过应用层拼接、中间件或FEDERATED引擎（已弃用）实现。
能跨，但必须分清是「同一MySQL实例下的多库」还是「不同MySQL服务器上的库」——前者原生支持，后者必须借助中间层或应用层拼接，不能靠一条SQL直接JOIN。
同一MySQL实例下跨库JOIN：用db_name.table_name前缀即可
只要两个数据库（比如 sales_db 和 user_db）在同一个MySQL服务进程里，且当前连接用户对两张表都有SELECT权限，就完全可以用标准JOIN语法，只需在表名前加上库名。
- 错误写法：
SELECT * FROM users JOIN orders ON users.id = orders.user_id（没指定库名，依赖USE切换，易错且不可靠） - 正确写法：
SELECT u.name, o.amount FROM user_db.users u INNER JOIN sales_db.orders o ON u.id = o.user_id - 注意别漏掉权限：用户必须同时有
user_db.users和sales_db.orders的查询权，否则报错ERROR 1142 (42000): SELECT command denied to user - 别在代码里硬编码
USE sales_db再查user_db.users——MySQL不认这种跨库引用，会提示Unknown table 'users'
跨MySQL实例（不同IP/端口）无法直接JOIN
MySQL协议本身不支持在一条SQL里连两个独立实例。你写SELECT * FROM db1.table1 t1 JOIN db2.table2 t2...时，如果db1和db2不在同一mysqld进程下，会直接报错ERROR 1146 (42S02): Table 'db2.table2' doesn't exist——它根本不会去另一台机器找。
- 常见误操作：以为改个DNS或加个链接字符串就能通，其实不行
- 替代方案只有三种：应用层两次查询后内存JOIN、用FEDERATED引擎（已弃用且不稳定）、或用DMS这类带查询路由能力的中间件
- FEDERATED在MySQL 8.0+默认禁用，启用需配置
federated=ON并重启，且远程表结构变更不会自动同步，容易查出脏数据
ORM里跨库JOIN要特别小心别触发N+1
比如SQLAlchemy里写session.query(User).join(Order)，如果User和Order映射到不同数据库，框架不会自动帮你跨实例发JOIN，而是可能退化成先查User、再为每个User单独查Order——也就是典型的N+1问题。
- 显式指定跨库关联时，得确保两个Model绑定的是同一个
Engine，且该Engine指向的是支持跨库的单实例 - 如果真要跨实例，别依赖ORM的
join()方法，改用session.execute(text("SELECT ..."))配合手动拼接结果 - Django ORM同理：
select_related()和prefetch_related()都只在单数据库内有效，跨库必须拆成多个QuerySet再Python层合并
最常被忽略的一点：跨库JOIN的性能瓶颈往往不在网络，而在锁和事务隔离级别。比如user_db.users被长事务占用时，sales_db.orders的JOIN可能被卡住，而你查的错误日志里只会显示“Lock wait timeout”，根本看不出是跨库引发的连锁阻塞。
