MySQL原生支持跨库JOIN，只需用db_name.table_name语法，前提是用户对各库表有SELECT权限；权限不足会报ERROR 1142；建议显式授权且所有表名带库前缀。
可以直接用 数据库名.表名 的方式在 JOIN 中引用其他库的表，不需要额外配置或权限放宽——只要当前用户对目标库有 SELECT 权限就行。
跨库 JOIN 的基本写法
MySQL 允许在同一个查询里混用不同数据库的表，语法和同库 JOIN 完全一致，只需把表名写成 db_name.table_name 形式即可：
SELECT u.name, o.order_id FROM user_db.users u JOIN order_db.orders o ON u.id = o.user_id;
注意：库名和表名之间用英文点号（.）连接，不能加引号；别名（如 u、o）仍然可以照常使用。
权限不足时会报什么错？
如果当前用户没有访问目标数据库的权限，执行时会直接报错：ERROR 1142 (42000): SELECT command denied to user 'xxx'@'%' for table 'orders'。这个错误里的 table 'orders' 实际指的是 order_db.orders，但错误信息不会显示库名，容易误判。
- 确认权限：运行
SHOW GRANTS FOR CURRENT_USER;，检查是否包含类似GRANT SELECT ON `order_db`.* TO ... - 临时补权：DBA 可执行
GRANT SELECT ON order_db.orders TO 'user'@'%';（最小权限原则，不建议直接给order_db.*） - 跨库查询无法绕过权限校验——哪怕两个库在同一台 MySQL 实例上也不行
视图或存储过程里用跨库表要注意什么？
在视图或存储过程中引用跨库表时，定义者权限（SQL SECURITY DEFINER）会影响实际执行时的权限检查点：
- 默认是
SQL SECURITY DEFINER，即按视图创建者的权限检查，不是调用者的权限 - 如果想让调用者用自己的权限访问跨库表，得显式声明
SQL SECURITY INVOKER - 存储过程里跨库更新（
UPDATE/DELETE）同样受权限限制，且事务能跨库生效
例如创建视图时指定调用者权限：
CREATE VIEW user_order_view AS SELECT u.name, o.total FROM user_db.users u JOIN order_db.orders o ON u.id = o.user_id WITH CASCADED CHECK OPTION SQL SECURITY INVOKER;
性能和锁会不会因为跨库变复杂？
不会。MySQL 的“跨库”只是逻辑命名空间隔离，物理上所有库都在同一个实例、同一组数据文件里。因此：
- JOIN 过程不增加网络开销，走的是本地 buffer pool 和索引扫描
- 锁机制（如行锁、间隙锁）和同库查询完全一致，InnoDB 不区分库边界
- 唯一影响性能的因素是：被 JOIN 的表是否建了合适的索引，以及统计信息是否准确——和库名无关
- 但要注意：如果两个库字符集或排序规则不同（比如
utf8mb4_0900_as_csvsutf8mb4_general_ci），JOIN 条件可能隐式转换，导致索引失效
跨库本身不带来额外复杂度，真正要花时间琢磨的，是字段类型匹配、索引覆盖、以及权限链路是否清晰——这些细节一旦漏掉，问题会藏得比较深。
