MySQL存储过程中跨库JOIN必须显式使用db_name.table_name格式，USE语句无效；权限校验基于调用者而非定义者，动态库名需PREPARE+EXECUTE实现且须白名单校验。
存储过程里写跨库JOIN，必须带库名前缀
USE语句在存储过程中完全无效，写了也白写。MySQL解析SQL时，所有未带库名的表都会默认去存储过程定义所在的库找，哪怕你前面刚执行过USE billing，下一行SELECT * FROM users照样报Table 'auth.users' doesn't exist（假设过程定义在auth库）。
正确做法只有一种：所有表名显式写成db_name.table_name格式。例如从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;
- 别名（如
u、i）照常可用，但别名本身不改变库上下文 - 两个库名都必须存在且拼写准确，大小写敏感取决于系统配置
- 字段重名时（比如两库都有
id），必须用别名限定，否则报Column 'id' in field list is ambiguous
动态库名只能走PREPARE + EXECUTE
如果库名来自参数（如IN target_db VARCHAR(64)），不能直接写SELECT * FROM target_db.users——MySQL会把它当字面量库名，而不是变量值。更不能用CONCAT拼字符串后直接EXECUTE，语法会错。
唯一可行路径是预编译：
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声明的局部变量 - 库名拼接前务必白名单校验，比如用
REGEXP '^[a-zA-Z0-9_]+$'，否则target_db传入billing; DROP TABLE auth.users --就完了 - 每次
PREPARE后必须DEALLOCATE PREPARE，否则下次调用可能触发Error 1470: Prepared statement not deallocated - ?占位符只支持值，不支持库名/表名等标识符——这是硬限制，没绕过办法
权限校验看的是调用者，不是定义者
即使你用root账号创建了存储过程，普通应用账号app_user@%调用时，MySQL仍会检查该账号是否拥有auth和billing两个库的SELECT权限。常见错误是只给定义者授了权，却忘了给调用者加：
GRANT SELECT ON auth.* TO 'app_user'@'%'; GRANT SELECT ON billing.* TO 'app_user'@'%';
-
SQL SECURITY DEFINER对跨库查询权限无效——它只影响过程内部对日志表、临时表等本库对象的操作 - 用
SHOW GRANTS FOR 'app_user'@'%'确认权限已生效，别信“我之前好像授过了” - 如果目标库名含特殊字符（如
my-db），授权时也要用反引号：GRANT SELECT ON `my-db`.* TO ...
批量汇总要注意事务边界和锁范围
跨库SELECT本身不涉及事务一致性问题，但一旦混入INSERT INTO summary_table SELECT ... FROM auth.users JOIN billing.invoices这类写操作，就得清醒：MySQL的InnoDB事务无法跨库原子回滚。一个库写成功、另一个库写失败，不会自动回退前者。
- 纯读场景（如报表生成）可放心跨库
JOIN，索引依然生效，执行计划正常 - 但高并发下大范围跨库
JOIN容易扩大锁范围，尤其当billing.invoices被频繁更新时，可能阻塞auth.users的读 - 批量汇总建议拆成两步：先用临时表存中间结果（
CREATE TEMPORARY TABLE tmp AS SELECT ...），再基于临时表聚合，减少跨库锁竞争 - 别指望
UNION ALL跨库能规避问题——它只是合并结果集，底层仍需分别访问各库，权限和性能约束一样存在
