FEDERATED引擎在MySQL 8.0默认不可用，因其未被编译进二进制包，需手动加载插件文件且格式严格；建表时CONNECTION必须为URL编码的mysql://协议格式；查不到数据常因远程连接失败而静默降级为空表；生产环境建议改用同步、双写或数据库网关等替代方案。
为什么 FEDERATED 引擎在 MySQL 8.0 默认不可用
MySQL 8.0 起，FEDERATED 引擎被默认禁用且不编译进服务，不是“关了开关就能用”，而是压根没加载。你执行 SHOW ENGINES; 看不到它，不是配置错了，是根本没启用模块。
必须在启动 mysqld 前，通过 --plugin-load-add=federated=ha_federated.so（Linux）或 ha_federated.dll（Windows）显式加载，且该插件文件得真实存在——很多二进制包（如官方 yum/apt 包）压根不附带这个文件。
- Percona Server 或 MariaDB 用户注意：
FEDERATED已被彻底移除，别白费时间找配置项 - Docker 部署时，需自定义
my.cnf并挂载插件文件，镜像默认不含ha_federated.so - 即使加载成功，
SELECT @@have_federated;返回NO也属正常——这变量已废弃，以SHOW ENGINES实际输出为准
建表语句里 CONNECTION 字符串怎么写才不报错
CONNECTION 不是普通字符串拼接，它是严格解析的 URL 格式，任何空格、多余斜杠、未转义特殊字符都会导致 ERROR 1432 (HY000): Can't create federated table. The data source connection string is not in the correct format。
正确格式是：'mysql://user:password@host:port/database/table'，注意：
- 协议头必须是
mysql://，不能省略，也不能写成mysql:或jdbc:mysql:// - 密码含
@、/、:时，必须 URL 编码（例如@→%40），否则解析器会截断 - 远程库名和表名区分大小写，且必须与目标库实际名称完全一致（包括下划线、数字位置）
- 端口不能省略，哪怕目标是 3306 —— 写成
host:3306，不能只写host
示例：
CREATE TABLE remote_user ( id INT, name VARCHAR(50) ) ENGINE=FEDERATED CONNECTION='mysql://root:pass%40123@192.168.1.100:3306:test_db:user_table';
FEDERATED 表查不出数据但也不报错？检查这三处
最常见现象：建表成功，SELECT * 返回空结果集，无错误提示，连慢日志都不记录——其实是远程连接建立失败后静默降级为“空表”。
- 远程 MySQL 必须开启
skip-networking=OFF且bind-address不能是127.0.0.1（否则只接受本地 socket 连接） - 远程用户权限要明确授予：不是只要
SELECT就行，还得有SELECT权限 + 对应库表的USAGE（部分版本要求） - 防火墙/安全组放行目标端口，且远程 MySQL 的
max_connections没被占满（FEDERATED每次查询都新建连接）
验证方式：在本地执行 mysql -u user -ppass -h remote_host -P port -e "SELECT 1"，能通才说明网络和认证层没问题。
替代方案比硬扛 FEDERATED 更靠谱
真正上线环境几乎没人用 FEDERATED，原因很实在：没有事务支持（远程操作无法回滚）、无连接池、超时不可控、排查链路长、且 MySQL 官方已标记为“deprecated”。
- 简单只读场景，用
mysqldump --where定期同步到本地临时表，配合EVENT自动刷新 - 需要实时性，改用应用层双写，或引入
MaxScale/ProxySQL做读写分离+跨节点路由 - 云环境优先考虑数据库网关类服务（如阿里云 DBLink、AWS RDS Custom Extensions），它们封装了连接管理与错误重试
如果你正卡在某个 FEDERATED 报错上，大概率不是参数调得不够细，而是该换思路了——它从来就不是为生产跨库设计的。
