在稍微上点规模的项目里，按业务线、按租户、按时间拆库是再常见不过的做法。拆完之后问题就来了：每个库里都有一张结构一模一样的表，比如 db_2023.order 和 db_2024.order，或者 tenant_a.user_log、tenant_b.user_log。要做一次全局统计或者批量修正数据时，很多同学的写法是在应用程序里循环连接每个库分别执行，再把结果拼起来。这样做不但代码啰嗦，事务和性能也难控制。其实 MySQL 本身就提供了不少手段来优雅地处理这类需求，下面逐一展开。
方案一：直接用全限定表名做跨库联合查询
如果库名是固定的、数量也不多，最直接的方式就是用 库名.表名 的全限定写法，把多个库里的同构表用 UNION ALL 拼在一起查询。前提是这些库在同一个 MySQL 实例上，且当前账号对每个库都有权限。
-- 假设 db_a 和 db_b 中都有 order 表 SELECT 'db_a' AS source_db, id, order_no, amount, created_at FROM db_a.`order` WHERE created_at >= '2024-01-01' UNION ALL SELECT 'db_b' AS source_db, id, order_no, amount, created_at FROM db_b.`order` WHERE created_at >= '2024-01-01' ORDER BY created_at DESC LIMIT 100;
这种写法的优点是简单直观，不需要任何额外组件，索引也能正常命中。缺点也很明显：库名和表名必须硬编码在 SQL 里，一旦新加一个库就要改 SQL，维护成本会随库的数量线性增长。所以它适合库数量少且稳定的场景，比如按年份归档的历史库。
另外要注意 UNION ALL 和 UNION 的区别：UNION 会对结果去重，涉及排序去重开销，一般统计场景用 UNION ALL 就够了。每个子查询里加一个来源标识列（如上面的 source_db），方便定位数据来自哪个库。
方案二：用 information_schema 动态发现同构表并生成 SQL
当库的数量不固定，或者你根本不想手写一堆库名时，可以先从 information_schema 里查出所有包含目标表的库，再动态拼出查询语句。information_schema.tables 记录了实例内所有库表信息，配合 GROUP_CONCAT 可以一行 SQL 生成完整的查询文本。
-- 自动找出所有包含 order 表的库，并生成 UNION ALL 查询
SELECT GROUP_CONCAT(
CONCAT(
'SELECT ''', table_schema, ''' AS source_db, id, order_no, amount FROM `',
table_schema, '`.`order`'
)
SEPARATOR ' UNION ALL '
) AS generated_sql
FROM information_schema.tables
WHERE table_name = 'order'
AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
执行后会得到一整段 SQL 字符串，复制出来执行即可。要注意 GROUP_CONCAT 默认最大长度是 1024 字节，库多的时候会被截断，需要先执行 SET SESSION group_concat_max_len = 1000000; 再查询。
这种方式把「维护库名清单」这件事交给了数据库自己，新增库后无需改任何代码。缺点是它生成的是静态文本，你还得拿去执行一次，适合低频的全局巡检、数据核对类任务。如果需要经常跑，可以把它和存储过程结合起来，下一步就讲。
方案三：存储过程加事件调度器实现自动化
要让「遍历所有库操作同构表」这件事自动跑起来，可以写一个存储过程，用游标遍历库名列表，配合 PREPARE 执行动态 SQL，最后用事件调度器定时触发。下面是一个把各库订单表数据汇总到 summary_db.order_total 的完整例子。
DELIMITER $$
CREATE PROCEDURE merge_order_data()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE dbname VARCHAR(64);
DECLARE cur CURSOR FOR
SELECT table_schema FROM information_schema.tables
WHERE table_name = 'order'
AND table_schema LIKE 'db\_%';
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur;
read_loop: LOOP
FETCH cur INTO dbname;
IF done THEN LEAVE read_loop; END IF;
SET @sql = CONCAT(
'INSERT INTO summary_db.order_total(source_db, order_no, amount) ',
'SELECT ''', dbname, ''', order_no, amount FROM `', dbname, '`.`order` ',
'WHERE stat_date = CURDATE()'
);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END LOOP;
CLOSE cur;
END$$
DELIMITER ;
存储过程的核心是 PREPARE 语句：因为表名不能是变量，必须先把完整 SQL 拼成字符串再预编译执行。拼接时库名要用反引号包住，防止库名里出现保留字或者特殊字符。此外强烈建议对库名做 LIKE 或白名单过滤，避免把系统库也扫进去。
有了过程之后，开启事件调度器就能定时执行：
SET GLOBAL event_scheduler = ON; CREATE EVENT ev_merge_order ON SCHEDULE EVERY 1 HOUR DO CALL merge_order_data();
这套方案的优点是完全在数据库内部闭环，不依赖应用代码和外部定时任务，挂到 crontab 都省了。缺点是动态 SQL 无法利用执行计划缓存，出错排查也比较麻烦，建议在过程里加上异常记录表，把每次执行的结果写下来方便回溯。
方案选择与性能注意事项
以上几种方式各有适用边界，简单总结一下：固定少量库选方案一，最直观；库数量经常变化选方案二或三；如果实例分布在不同机器上，那跨库 SQL 根本行不通，只能走应用层聚合，或者引入 MyCat、ShardingSphere 这类中间件做逻辑分库，让上层无感知地执行全局查询。
性能方面有几点务必留意。第一，跨库 UNION ALL 本质上是多个独立查询的结果拼接，每个子查询都要能走上索引，千万别让其中一个库的表没有索引而拖慢整体。第二，游标加动态 SQL 的方式是串行执行的，库多表大时耗时可观，可以考虑在存储过程里只做轻量汇总，把大查询交给汇总表或数仓。第三，批量写操作记得控制事务大小，游标循环里每张表一个事务比整个循环一个大事务要安全得多，避免长事务锁等待和 binlog 膨胀。
最后提醒一点权限问题：跨库操作要求当前账号对每一个目标库都有相应权限，生产上建议单独建一个只赋予最小权限的账号给汇总任务使用。把动态拼接 SQL 的输入（库名）严格限定在 information_schema 查出来的白名单内，也能有效避免 SQL 注入风险。按照这个思路组合运用，多库同构表的操作就能做到既省事又可控。