MySQL原生支持跨库查询，只需用db_name.table_name语法显式指定表，前提是用户对各库表有相应SELECT权限；权限不足会报ERROR 1142；建议所有表名都带库前缀，避免依赖USE切换；纯SELECT无事务问题，但跨库写操作无法原子回滚。
MySQL跨库查询直接用db_name.table_name就行
只要用户对两个库都有对应权限，MySQL原生就支持跨库联合查询，不需要视图、链接服务器或额外配置。核心就是把表名写成带数据库前缀的完整形式：database1.users JOIN database2.orders。这是MySQL最基础也最稳定的跨库方式，不是“黑魔法”，也不是临时 workaround。
权限不足会导致ERROR 1142 (42000): SELECT command denied
即使SQL语法完全正确，执行时仍可能报这个错——说明当前用户没被授予目标库中对应表的权限。注意：不是只要登录了就能查，必须显式授权：
GRANT SELECT ON mydb1.users TO 'appuser'@'%';GRANT SELECT ON mydb2.orders TO 'appuser'@'%';- 执行完记得
FLUSH PRIVILEGES;
常见疏漏是只给了主库权限，忘了给被JOIN的库授读权限；或者用GRANT ALL ON *.*但限制了host（比如只给了'appuser'@'localhost'，而应用连的是远程IP）。
别在USE语句里依赖当前库上下文
很多人习惯先USE db1;再写SELECT * FROM users JOIN db2.orders，这没问题；但反过来——如果先USE db2;，再写SELECT * FROM db1.users JOIN orders——就容易误以为orders自动指向db2.orders，其实它确实会，但一旦逻辑变复杂（比如子查询里嵌套、UNION里混用），隐式库名极易出错。建议：
- 所有表名都显式带上库名，例如
db1.users、db2.orders，不省略 - 避免靠
USE切换来“简化”写法，尤其在存储过程或长SQL中 - 如果涉及同名表（如两个库都有
logs），不加库名会直接报ERROR 1066 (42000): Not unique table/alias
性能和事务边界要注意：跨库不影响索引，但影响事务一致性
跨库查询能正常使用目标表上的索引，执行计划里也能看到type=ref或key=xxx，这部分和单库无异。但关键限制在于：MySQL的事务无法跨库回滚。也就是说：
- 你可以在一个事务里对
db1.t1和db2.t2做UPDATE，语法上允许 - 但如果中途失败，InnoDB只能保证本库内回滚，另一个库的变更不会撤销
- 所以涉及跨库写操作时，必须自行实现补偿逻辑或改用应用层事务协调
纯SELECT跨库查询没这个问题，但只要混入INSERT/UPDATE/DELETE，就得立刻意识到：这不是单机ACID能兜住的场景。
