目录
[1、FEDERATED 引擎](#1、FEDERATED 引擎)
警告前置：
FEDERATED 引擎在 MySQL 8.0 中已被彻底移除，且在生产环境中强烈不推荐使用。
前沿
当一个SQL执行的时候，会经过客户端，MySQL的服务层，存储引擎层。具体链路可参考：
MySQL中select查询语句的执行过程
https://dyclt.blog.csdn.net/article/details/148472938?spm=1011.2415.3001.5331
如下所示：
以下主要是存储引擎的示例图：
1、FEDERATED 引擎
1.1、介绍
FEDERATED存储引擎 是 MySQL 的一个特殊存储引擎，它允许你在本地数据库中创建一个"虚拟表" ，该表实际上指向远程 MySQL 服务器上的真实表。
- 本地：你执行 SQL 的 MySQL 实例（称为 本地服务器）
- 远程：数据实际存储的 MySQL 实例（称为 远程服务器）
当你查询本地的 FEDERATED 表时，MySQL 会自动将请求转发到远程服务器，获取结果后返回给你。
如下所示：
本质：透明代理 ------ 让远程表看起来像本地表。
1.2、核心工作原理
本地MySQL实例 远程MySQL实例
CREATE TABLE 真实表：
federated_t remote_table
ENGINE=FEDERATED
查询语句：
sql
SELECT * FROM federated_t 执行流程
-
应用连接本地 MySQL
-
执行 select * from federated_table
-
本地 MySQL 通过 FEDERATED 引擎：
-
解析表定义中的远程连接信息
-
建立到远程 MySQL 的新连接
-
将原始 SQL 重写并发送给远程服务器
-
-
远程服务器执行查询，返回结果
-
本地 MySQL 接收结果，返回给应用
🔑 关键点：所有数据都从远程拉取到本地再返回，本地不存储任何数据。
1.3、如何使用
步骤 1：确保 FEDERATED 引擎已启用
sql
-- 查看是否支持 FEDERATED
SHOW ENGINES;
-- 如果未启用，需在 my.cnf 中添加（MySQL 5.7 及以下）：
[mysqld]
federated⚠️ 注意：MySQL 8.0+ 不再支持 FEDERATED。
步骤 2：在远程服务器创建真实表
sql
-- 远程服务器 (192.168.1.100)
CREATE DATABASE remote_db;
USE remote_db;
CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(100),
price DECIMAL(10,2)
);
INSERT INTO products VALUES (1, 'Laptop', 5000.00);步骤 3：在本地服务器创建 FEDERATED 表
sql
-- 本地服务器
CREATE DATABASE local_db;
USE local_db;
CREATE TABLE federated_products (
id INT PRIMARY KEY,
name VARCHAR(100),
price DECIMAL(10,2)
)
ENGINE=FEDERATED
CONNECTION='mysql://user:password@192.168.1.100:3306/remote_db/products';
CONNECTION格式：mysql://用户名:密码@主机:端口/数据库名/表名
步骤 4：像本地表一样查询
sql
-- 在本地执行
SELECT * FROM federated_products;
-- 返回: (1, 'Laptop', 5000.00)
-- 甚至可以 JOIN（但性能极差！）
SELECT o.order_id, p.name
FROM orders o
JOIN federated_products p ON o.product_id = p.id;2、优缺点
2.1、支持的操作
如下所示：
| 操作 | 是否支持 | 说明 |
|---|---|---|
| select | 支持 | 基本查询 |
| insert | 支持 | 数据插入到远程表 |
| update | 支持 | 更新远程数据 |
| delete | 支持 | 删除远程数据 |
| where 条件下推 | ⚠️ 部分 | 简单条件可下推，复杂条件全表拉取 |
| join | 不支持（性能灾难） | 本地表 JOIN FEDERATED 表会拉取全表 |
不支持的操作
-
索引无法利用（远程索引对本地不可见）
-
事务不跨服务器（本地事务 ≠ 远程事务）
-
不支持 alter table
-
外键约束无效
2.2、致命缺陷与风险
1.性能极差
-
每次查询都建立新连接（除非连接池）
-
无法下推复杂条件：如 where func(column)=value 会导致全表扫描
-
join 操作会将远程表全量拉到本地再关联;
📉 示例：远程表 100 万行，select * from fed_table where id = 1
→ 如果 id 有索引且条件简单，可能只查一行
→ 但如果条件是 where name like '%laptop%'，全表拉取！
2.连接管理问题
-
每个 FEDERATED 表查询都会新建到远程的连接
-
高并发下极易耗尽远程 MySQL 的 max_connections
3.安全风险
-
密码明文写在 create table语句中
-
权限难以控制（需给本地用户远程 DB 的访问权限）
4.可靠性差
-
远程服务器宕机 → 所有查询失败
-
网络抖动 → 查询超时
-
无重试机制
5.调试困难
-
慢查询日志显示在本地，但瓶颈在远程
-
执行计划（EXPLAIN）不准确
3、最佳实践
3.1、替代方案
最佳实践 ：不要让数据库直接通信，通过应用层或消息队列解耦。
3.2、使用场景
-
临时数据迁移/验证
- 快速比对两个库的数据
- 一次性导出少量数据
-
开发/测试环境
- 模拟分布式环境（但不要用于压测）
-
遗留系统改造过渡
- 逐步替换，而非长期依赖
🚫 永远不要在以下场景使用：
- 高并发生产系统
- 核心交易链路
- 大数据量查询
总结
FEDERATED 是一个"设计上就注定失败"的特性。它试图用"透明"解决分布式问题，却忽略了网络、性能、一致性的本质约束。
参考文章：