Merge存储引擎不能直接用于归档操作，因为它只是将多个MyISAM表逻辑合并为虚表，不存储数据、不支持跨表原子DML，且MySQL 8.0已移除其支持。
Merge 存储引擎本身不归档数据，它只做“逻辑合并”——把多个已存在的 MyISAM 表当一张表来查。想用它支撑归档场景，必须配合外部归档动作（比如先用 pt-archiver 或 INSERT INTO ... SELECT 把旧数据挪到独立的 MyISAM 表里），再把它们 union 进 Merge 表。直接在生产表上建 Merge 是无效且危险的。
为什么 Merge 表不能直接用于归档操作
Merge 表是虚表，不存数据，也不参与 DML 的实际执行路径。它只是把查询路由到底层 MyISAM 表。所以：
-
INSERT到 Merge 表时，只写入INSERT_METHOD指定的某一张底层表（FIRST/LAST），不会自动按时间分发 -
DELETE或UPDATE无法跨底层表原子执行；若底层表结构稍有差异（比如索引顺序不同），整个 Merge 表会不可用 - 底层表必须全是 MyISAM —— 而现代 MySQL 默认引擎是 InnoDB，强制切换存储引擎可能引发权限、事务、崩溃恢复等兼容性问题
- MySQL 8.0+ 已移除 MERGE 存储引擎支持，官方文档明确标记为 deprecated since 5.7, removed in 8.0
如何让 Merge 表真正服务于归档查询
核心思路：归档动作（搬数据）和查询抽象（Merge 合并）必须解耦。归档由外部工具完成，Merge 仅作为查询入口。
- 归档阶段：用
pt-archiver将orders中created_at < '2024-01-01'的数据导出到新表orders_2023，并确保该表ENGINE=MyISAM - 结构校验：所有待 union 的表（如
orders_2023、orders_2024）字段名、类型、长度、顺序、索引定义必须完全一致，否则CREATE TABLE ... ENGINE=MERGE会静默失败或后续查询报错 - 动态维护：新增归档年份时，需
ALTER TABLE all_orders UNION=(orders_2023,orders_2024,orders_2025)，不能只追加；删除某年数据需先从 UNION 列表中剔除，再DROP TABLE - 避免写入污染：生产写入必须绕过 Merge 表，只写原表（如
orders_current），归档后才将历史表加入 Merge —— 否则INSERT_METHOD=LAST可能把新订单误插进 2023 年表
Merge 查询性能与常见翻车点
Merge 表查询本质是并发扫描所有底层表，再合并结果。这带来几个硬限制：
- 没有跨表索引优化：
SELECT * FROM all_orders WHERE order_date = '2023-06-01'会全表扫orders_2023、orders_2024、orders_2025三张表，即使只有 2023 表含该日期 - UNION 列表越长，查询开销越大；超过 10 张表时，
SHOW CREATE TABLE输出可能被截断，导致运维误判结构 - 如果某张底层表损坏（如 MyISAM 索引文件丢失），整个 Merge 表
SELECT会直接报错：ERROR 1017 (HY000): Can't find file: 'all_orders' (errno: 2 - No such file or directory) -
EXPLAIN对 Merge 表无效，只能对单个底层表分别EXPLAIN，无法预估合并后的实际耗时
真正需要长期归档 + 高频历史查询的场景，Merge 是过渡方案而非终点。它适合短期、低QPS、结构极稳定的归档需求；一旦涉及分区裁剪、冷热分离或跨引擎查询，应尽快迁移到分区表（PARTITION BY RANGE）或外部检索系统（如 Elasticsearch）。最易被忽略的一点：MySQL 8.0 环境下，SHOW ENGINES 已不显示 MRG_MYISAM，任何依赖它的脚本都会失效。
