mysql存储过程跨库操作必须显式使用db_name.table_name格式，use语句无效；权限校验基于调用者而非定义者；动态库名需prepare+execute并严格校验白名单。
MySQL存储过程本身不能“切换”数据库上下文，但能跨库操作——前提是所有表引用都显式带上 db_name.table_name 格式。这不是权宜之计，而是唯一可靠方式。
为什么 USE 在存储过程中基本无效
执行 USE other_db 后紧接着写 SELECT * FROM users，MySQL 仍会去当前默认库（即存储过程定义所在的库）里找 users 表。报错信息通常是 Table 'current_db.users' doesn't exist，哪怕你刚 USE 过别的库。
-
USE只影响客户端连接的默认数据库，不改变存储过程内部 SQL 解析时的隐式库上下文 - 存储过程编译时就锁定了对象解析规则，运行时不会动态重绑定库名
- 唯一能绕过这个限制的方式：所有表名都写成带库前缀的全路径
静态跨库查询：直接写 db1.users 和 db2.orders
当目标库名固定、无需动态变化时，这是最简洁安全的做法。比如从 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或更细粒度） - 不能依赖
SQL SECURITY DEFINER来绕过跨库权限检查——MySQL 会校验调用者（INVOKER）的实际权限 - JOIN 跨库时，索引仍有效，但锁范围可能扩大；避免在高并发场景下做大范围跨库 JOIN
动态库名必须走 PREPARE + EXECUTE 流程
如果库名来自参数（如 IN db_name VARCHAR(64)），就不能直接拼接进 SQL，因为标识符（库名/表名）不支持 ? 占位符。必须用字符串拼接 + 预编译：
SET @sql = CONCAT('SELECT * FROM ', db_name, '.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 注入
权限校验只看调用者，不是定义者
即使你用 root 创建了存储过程，普通应用账号 app_user@% 调用时，MySQL 仍会检查该账号是否拥有目标库的 SELECT 权限。常见错误是只给定义者授了权，却忘了给调用者加：
GRANT SELECT ON billing.* TO 'app_user'@'%';
-
SQL SECURITY DEFINER对跨库 SELECT 无效，它只控制过程内对本库对象（如日志表）的操作权限 - 若必须用 DEFINER 权限查跨库数据，得把目标库权限也授予该 DEFINER 用户——但要评估账号暴露风险
- 权限变更后需执行
FLUSH PRIVILEGES，否则可能延迟生效
真正容易被忽略的点是：跨库查询的性能边界和锁行为完全不同于单库操作。哪怕语法跑通了，JOIN 涉及两个库的表时，MySQL 无法利用两库各自的优化器协同工作，事务隔离级别也可能意外升级。上线前务必在真实数据量下压测。
