MySQL跨库查询需用database_name.table_name格式写全路径名，数据库名与表名须分别用反引号包裹，不可整体加引号；JOIN时所有跨库字段必须显式带库前缀或表别名限定，且用户需具备各库表SELECT权限。
跨库查询时如何正确写表的全路径名
MySQL 支持直接在 SELECT、JOIN 等语句中用 database_name.table_name 形式引用其他数据库的表，无需额外配置或权限特殊处理（只要用户有目标库表的 SELECT 权限）。关键在于语法必须严格：数据库名和表名之间用英文点号 . 连接，且不能加反引号包裹整个路径（如 `db1.user` 是合法的，但 `db1`.`user` 才是推荐写法；而 `db1.user` 会被视为一个名为 “db1.user” 的单表名，查不到）。
- 正确写法：
db1.users或`db1`.`users` - 错误写法：
`db1.users`（反引号包住带点的字符串 → 解析为单个标识符） - 别名仍可照常使用：
db1.orders AS o或`db1`.`orders` o - 如果数据库名/表名含特殊字符或关键字，必须分别用反引号包裹：
`my-db`.`order-list`
JOIN 多库表时要注意权限和字段歧义
跨库 JOIN 和同库 JOIN 语法一致，但容易因权限或命名冲突出错。比如用户对 db2 没有 SELECT 权限，执行时会报错 ERROR 1142 (42000): SELECT command denied to user；又或者两个库都有 id 字段，不显式指定别名会导致 Column 'id' in field list is ambiguous。
- 务必确认当前用户对所有涉及的库表都有
SELECT权限（可用SHOW GRANTS;查看） - 所有可能重名的字段（尤其是
id、created_at）必须用表别名限定，例如u.id、o.order_id - 避免在
USING子句中跨库使用，建议统一改用ON显式关联，更可控 - 示例：
SELECT u.name, o.amount FROM db1.users u JOIN db2.orders o ON u.id = o.user_id;
视图或存储过程中引用跨库表的注意事项
在创建视图（CREATE VIEW）或存储过程时用到跨库表，MySQL 会记录当时用户的 DEFINER（定义者），后续调用时权限检查以 DEFINER 为准，而非调用者。这意味着：如果视图定义者是 'admin'@'localhost'，但普通用户执行 SELECT * FROM my_view，实际查的是 admin 的权限上下文 —— 如果 admin 没有 db2 的权限，视图就会执行失败。
- 创建跨库视图前，先用
SELECT语句手动验证是否能跑通 - 优先设
SQL SECURITY DEFINER并确保 DEFINER 用户拥有全部依赖库表权限 - 若需适配多租户或权限隔离场景，应避免跨库视图，改用应用层拼装或临时表
- 存储过程中跨库操作同样受 DEFINER 权限约束，
EXECUTE权限 ≠ 数据访问权限
性能与锁表现：跨库不等于跨实例
MySQL 的“跨数据库”只是逻辑隔离，所有库默认在同一实例、同一文件系统、共享缓存和连接线程。因此跨库查询不会带来网络延迟或分布式事务开销，但也不会自动规避锁竞争 —— 比如 db1.t1 和 db2.t2 同时被更新，仍可能因行锁/表锁相互阻塞。
- 执行计划（
EXPLAIN）里看到的table列会显示完整路径，如db2.orders，但type、key等指标判断方式与单库无异 - 没有跨库索引合并优化，无法利用
db1.users.name和db2.logs.user_name自动建立联合索引 - 大表跨库 JOIN 容易触发磁盘临时表（
Using temporary; Using filesort），注意tmp_table_size和max_heap_table_size配置 - 备份或主从同步时，跨库查询本身不影响一致性，但若业务强依赖跨库 JOIN 结果，需确保主从库结构完全一致
跨库全路径引用本身很简单，真正容易翻车的地方在于权限继承关系、字段作用域混淆，以及误以为“不同库=不同实例”导致的性能误判。
