MySQL存储过程跨库查询：避开那些“坑你没商量”的陷阱
跨库查询必须显式写库名，不能靠 USE 切换
这事儿得先拎清楚：在MySQL存储过程里，USE语句基本就是个“摆设”。你以为执行了USE other_db，后续查询就能自动切换到那个库？太天真了。它根本不会改变后续SQL语句的默认数据库上下文。结果就是，所有表引用都必须老老实实带上库名前缀，否则等着你的就是经典的Table 'xxx' doesn't exist错误——哪怕连接用户对目标库拥有全套权限，也照样报错。
最常见的错误写法，就是先USE other_db，然后直接写SELECT * FROM users。实际上，USE在存储过程里几乎不起作用，后续查询依然按照调用时的默认库来解析。
- 正确姿势永远是：
SELECT * FROM other_db.users - 如果库名或表名是动态的，那就得用
CONCAT配合PREPARE来拼接SQL字符串，直接变量插值是行不通的。 - 特别注意：库名、表名这类标识符，在
PREPARE语句中不能用参数占位符?来替代，否则会直接语法报错。
调用者权限决定能否查到跨库数据，不是定义者权限
权限问题，是另一个容易让人栽跟头的地方。MySQL存储过程默认以DEFINER（定义者）的权限执行，对吧？但一涉及到跨库查询，真正起作用的，其实是调用者（INVOKER）对目标库的权限。这意味着，即使用一个高权限的DBA账号创建了存储过程，当普通应用账号去调用时，如果该账号没有目标库的权限，照样会收到Access denied的拒绝信。
- 务必确认调用存储过程的账号，对目标库拥有相应的
SELECT权限。例如：GRANT SELECT ON other_db.* TO 'app_user'@'%'。 - 别指望用
SQL SECURITY DEFINER这个属性来绕过权限检查——它只管过程内部的其他操作（比如写入某个日志表），但覆盖不了跨库SELECT时的权限校验。 - 如果非得用DEFINER的权限去查跨库数据，唯一的办法就是把目标库的权限也授予这个DEFINER用户，同时你得确保这个账号足够安全可信。
动态库名需用 PREPARE + EXECUTE，不能直接拼字符串
当库名需要通过参数动态传入时（比如参数db_name VARCHAR(64)），直接写SELECT * FROM db_name.table_name是行不通的。MySQL会把它当成一个名叫“db_name”的数据库，而不是变量里存储的值。
这时候，必须走预编译语句（Prepared Statement）的流程，否则不是语法错误，就是查错了地方：
SET @sql = CONCAT('SELECT * FROM ', db_name, '.users WHERE id = ?');
PREPARE stmt FROM @sql;
EXECUTE stmt USING in_id;
DEALLOCATE PREPARE stmt;
- 注意，
@sql是用户变量，得用SET来赋值，不能用DECLARE声明的局部变量直接拼接。 ?占位符只支持传递值（比如ID），不支持库名、表名这类标识符。所以库名必须作为字符串的一部分拼接进去，值才用USING子句传递。- 每次执行完
PREPARE，记得DEALLOCATE，否则可能会遇到MySQL Error 1470: Prepared statement not deallocated这样的错误。
跨库 JOIN 性能差、锁范围难控，别轻易上
在存储过程里写跨库JOIN，像SELECT a.id, b.name FROM db1.t1 a JOIN db2.t2 b ON a.ref = b.id，看起来确实方便，但背后的代价可不小。这种操作需要跨数据库引擎拉取数据，往往无法有效利用目标表上的索引，执行计划也容易失真。
- 性能杀手：跨库JOIN时，MySQL默认使用Block Nested-Loop算法，内存消耗巨大，慢查询的概率直线上升。
- 锁的噩梦：锁行为变得难以预测。即使你只是读取
db2.t2，也可能因为JOIN操作触发目标库上的元数据锁（MDL），从而阻塞其他会话的DDL操作（比如加字段、改表结构）。 - 更稳妥的方案：通常建议分两步走。先从
db1.t1查出ID列表，再用IN子句去查询db2.t2；或者干脆把数据聚合的逻辑放到应用层来处理。
说实话，真正必须使用跨库关联的场景少之又少。多数情况下，这暴露出的是数据库设计初期，业务边界没理清的问题。一旦发现存储过程里频繁出现跨库JOIN，那就是一个强烈的信号：是时候重新评估你的分库逻辑了。
