mysql存储过程无法通过use切换默认数据库，唯一跨库方式是显式使用db_name.table_name全路径；use仅影响客户端上下文，过程内sql解析始终基于定义时库；权限校验严格按调用者（invoker）实时执行，且动态库名须经白名单校验后通过prepare+execute拼接。
MySQL存储过程不能切换默认数据库上下文，但能跨库操作——唯一可靠方式是所有表名都写成 db_name.table_name 格式。
为什么 USE db_name 在存储过程中无效
执行 USE billing 后紧接着写 SELECT * FROM users，MySQL 仍会去当前定义存储过程的库（比如 auth）里找 users 表，报错通常是 Table 'auth.users' doesn't exist。
-
USE只影响客户端连接的默认库，不改变存储过程内部 SQL 解析时的隐式库上下文 - 存储过程编译时就锁定了对象解析规则，运行时不重绑定库名
- 哪怕你用
root创建过程，普通账号调用时也必须对目标库有权限——校验的是调用者（INVOKER），不是定义者
静态跨库查询：直接写全路径表名
目标库名固定时，这是最简洁安全的做法。例如从 auth.users 关联查 billing.invoices：
SELECT u.name, i.amount FROM auth.users u JOIN billing.invoices i ON u.id = i.user_id WHERE u.id = in_user_id;
- 必须确保调用者账号对
auth和billing都有对应权限（如SELECT） - JOIN 跨库时索引依然有效，但锁范围可能扩大；高并发场景下避免大范围跨库 JOIN
- 别指望
SQL SECURITY DEFINER绕过权限检查——MySQL 不认这个
动态库名必须用 PREPARE + EXECUTE 拼接
如果库名来自参数（如 IN target_db VARCHAR(64)），不能直接拼进 SQL，因为标识符不支持 ? 占位符：
SET @sql = CONCAT('SELECT * FROM ', target_db, '.users WHERE id = ?');
PREPARE stmt FROM @sql;
EXECUTE stmt USING in_id;
DEALLOCATE PREPARE stmt;
-
@sql必须是用户变量（SET @sql = ...），不能用DECLARE声明的局部变量 - 每次
PREPARE后必须DEALLOCATE PREPARE，否则可能触发Error 1470: Prepared statement not deallocated - 拼接前务必白名单校验库名，比如用正则
^[a-zA-Z0-9_]+$，否则极易 SQL 注入
跨实例或异构数据库不能靠存储过程原生实现
MySQL 存储过程本身不支持连接其他 MySQL 实例，更不支持直连 PostgreSQL、Oracle 等异构库。
-
external_link()函数不是 MySQL 官方函数，实际不存在；网上示例多为虚构或混淆了其他数据库/中间件能力 - FEDERATED 引擎可映射远程表，但它不支持事务、性能差、维护成本高，且 MySQL 8.0+ 默认禁用
- 真正需要跨实例同步或交互，得靠应用层分别连接、ETL 工具、或者数据库复制（如 GTID + CHANGE MASTER）
最容易被忽略的一点：跨库操作的权限不是“一次授权终身有效”，而是每次调用都实时校验调用者账号在各目标库上的具体权限——漏授一条 SELECT 就直接报错，不会静默降级。
