FEDERATED引擎是远程表代理，不存数据只存结构，所有DML操作实时转发至远程MySQL执行；适用于多独立实例间轻量联合查询、网络稳定、结构不变且可接受无本地事务的场景。
FEDERATED 存储引擎不是本地数据容器，而是一个远程表代理 —— 它本身不存任何数据，只保存结构定义，并把所有 SELECT、INSERT、UPDATE、DELETE 请求实时转发给远程 MySQL 实例执行。
它适合的场景非常具体，不适合泛泛而谈“分布式”或“高可用”，关键看是否满足以下真实条件：
什么时候该用 FEDERATED？看这三点是否同时成立
你有多个独立运行的 MySQL 实例，且它们之间没有复制关系，但需要临时/轻量级地联合查询；
网络延迟可控（比如同机房或专线），且远程库不频繁变更表结构；
业务能接受无本地事务一致性保障，也不依赖 ALTER TABLE、DROP TABLE 等 DDL 操作。
FEDERATED 表创建时最常踩的坑
- MySQL 启动时没加
--federated参数，或者配置文件里漏了federated（不是plugin-load或loose-federated） -
CONNECTION字符串写错：必须是完整 URL 格式'mysql://user:pass@host:port/dbname/tablename'，端口不能省略，密码里含特殊字符要 URL 编码 - 远程库用户没被授予对应表的权限，且注意：本地
FEDERATED表的权限检查只发生在本地，但实际执行靠远程用户权限 - 建表语句中列定义和远程表必须完全一致（类型、长度、是否允许 NULL、默认值），否则查询可能返回乱码或截断
FEDERATED 查询为什么慢？根本原因不在 SQL 本身
每次查询都会建立新连接（不复用）、走完整 TCP 握手 + 认证 + 协议解析流程；
结果集从远程逐行拉回，无法流式处理，大结果集容易触发 max_allowed_packet 限制；
不支持下推 WHERE 条件优化 —— 比如 SELECT * FROM fed_tab WHERE id > 1000，引擎会先拉全表再本地过滤（除非远程表有索引且条件能被识别为可下推，但行为不稳定）；
没有统计信息，优化器对 FEDERATED 表永远估算为 1000 行，可能导致 JOIN 顺序错误。
替代方案比硬扛 FEDERATED 更值得优先考虑
如果发现经常要 JOIN 本地表和 FEDERATED 表，或需要分页、排序、聚合，基本说明它已超出设计边界；
更务实的做法是：用 mysqldump + 定时同步建临时表，或用 SELECT ... INTO OUTFILE + LOAD DATA INFILE 做轻量 ETL；
若必须实时，直接在应用层用两个连接分别查再合并，反而可控性更强、错误可捕获、超时可设、重试可配。
真正用好 FEDERATED 的人，往往只把它当“数据库层面的 curl”，而不是“分布式表”。它的脆弱点不在语法，而在你对网络、权限、结构一致性的掌控力 —— 这些地方一旦松动，问题就不是报错，而是静默错乱。
