FEDERATED引擎

入门

MySQL引擎主要有以下几种：

1. MyISAM：这是MySQL 5.5.5之前的默认存储引擎，不支持事务、外键约束和聚簇索引，适用于读多写少的场景。
2. InnoDB：这是MySQL 5.5.5之后的默认存储引擎，支持事务、外键约束、行级锁和聚簇索引，适用于需要事务支持和并发读写的场景。
3. MEMORY：也称为HEAP存储引擎，数据存储在内存中，速度快但重启后数据会丢失，适用于临时表或缓存。
4. MERGE：允许将多个MyISAM表合并为一个逻辑表，适用于数据仓库等场景。
5. CSV：使用CSV文件作为底层数据存储，适用于数据导入导出。
6. BLACKHOLE：类似于/dev/null，写入的数据会立即消失，适用于数据复制或日志记录。
7. ARCHIVE：适用于存储大量归档数据，不支持索引，压缩率高。
8. NDB：也称为NDBCLUSTER，适用于分布式数据库环境。
9. FEDERATED：允许在一个MySQL服务器上访问远程MySQL服务器上的表，实现了数据的分布式存储。

关于FEDERATED引擎的优缺点：

优点：

1. 节省存储空间和网络带宽：不需要复制数据到不同的MySQL实例里，而是直接使用远程MySQL实例中的数据。
2. 跨数据库服务器进行数据访问：可以跨数据库服务器进行数据访问。
3. 简化数据访问：访问该引擎的表就像是访问本地表一样，简化了数据访问过程。
4. 支持分布式查询：可以在不同的MySQL服务器之间共享数据，而不需要复制或进行数据同步。

缺点：

1. 性能问题：select count(*)、select * from limit M, N等语句执行效率非常低，数据量较大时存在严重问题。
2. 不支持索引：FEDERATED表通常不支持索引，导致性能不佳和网络负载过重。
3. 不支持ALTER TABLE：不支持ALTER TABLE或直接修改表结构的任何数据定义语言语句。
4. 不支持事务：FEDERATED引擎不支持事务。
5. 安全性问题：安全性需要通过federated表定义来处理。
6. 依赖网络性能：速度取决于网络和其他因素。

综上所述，FEDERATED引擎适用于需要跨数据库服务器进行数据访问且对性能要求不高的场景，但在高并发读写和需要事务支持的场景下应谨慎使用。

使用

FEDERATED存储引擎是MySQL中的一种特殊存储引擎，主要用于访问远程数据库中的数据。这种引擎允许在本地创建一个表结构文件（fed_tab.frm），而实际的数据则存储在远程服务器上。

使用场景

FEDERATED引擎特别适用于以下几种情况：

1. 跨服务查询：当需要从不同数据库实例或服务器访问数据时，可以使用FEDERATED引擎来实现跨实例的数据连接。
2. 数据库迁移和分库：用于将数据从一个数据库迁移到另一个数据库，或者在多个数据库之间进行数据共享。
3. 特殊应用：例如在某些开发应用中，通过FEDERATED引擎可以直接与远程数据表同步，从而简化了数据管理流程。

功能特点

• 不支持事务和某些DML操作：虽然FEDERATED引擎提供了对远程数据的访问能力，但它并不支持事务处理和一些特定的数据定义语言（DDL）操作。
• 批量插入优化：为了提高性能，FEDERATED引擎支持批量插入处理，可以将多行数据一次性发送到远程表。
• 结构一致性要求：创建FEDERATED表时，本地表的结构必须完全与远程表的结构相同。

启用方法

要启用FEDERATED存储引擎，首先需要确保MySQL安装时已经配置了该引擎。可以通过以下步骤来启用和使用FEDERATED引擎：

1. 检查是否已启用：进入命令行输入show engines;查看FEDERATED的状态是否为NO，如果是，则需要手动启用。
2. 添加配置选项：在配置文件中添加相应的选项并重启服务。例如，在CONNECTION选项中指定如何连接到远程服务器上的连接字符串。
3. 创建表：使用CREATE TABLE语句创建FEDERATED表，并指定远程表的名称和连接字符串。

注意事项

• 数据同步问题：由于FEDERATED引擎只在本地存储表结构文件，因此无法直接修改远程表的数据。如果需要更新远程表的数据，可能需要通过其他方式手动触发更新。
• 性能考量：尽管批量插入可以提升性能，但在高并发场景下仍需注意网络延迟和带宽限制的影响。

综上所述，FEDERATED存储引擎提供了一种高效且灵活的方式来访问远程数据库中的数据，适用于多种复杂的业务需求。然而，在使用过程中需要注意其局限性和性能优化策略。

主从架构下不建议使用

不建议使用FEDERATED存储引擎会导致MySQL主从复制出现异常的原因主要在于FEDERATED存储引擎的特性及其对数据一致性和复制机制的影响。

首先，FEDERATED存储引擎允许本地MySQL表访问远程MySQL数据库中的数据，而不使用复制或集群技术。这意味着本地表的数据实际上存储在远程数据库中，本地只存储表的结构。这种设计虽然提供了灵活性，但也带来了数据一致性和复制的问题。

在MySQL的主从复制架构中，主库的数据变更会通过二进制日志（binlog）传递到从库，从库根据这些日志进行数据同步。然而，FEDERATED存储引擎的数据并不存储在本地，而是存储在远程数据库中。因此，当主库发生数据变更时，这些变更无法直接通过binlog传递到从库，因为从库的FEDERATED表并没有实际的数据存储。这就导致了主从复制的一致性问题，因为从库无法正确反映主库的数据变更。

此外，FEDERATED表不支持通常意义上的索引，因为对表数据的访问是远程处理的。这意味着，对于需要全表扫描的查询，服务器会从远程表中获取数据，这不仅效率低下，还可能导致主从复制过程中的延迟和数据不一致。

综上所述，由于FEDERATED存储引擎的远程数据访问特性和对索引的支持不足，它会导致MySQL主从复制出现异常，因此不建议在需要主从复制的场景中使用FEDERATED存储引擎。

不建议在需要主从复制的场景中使用FEDERATED存储引擎，主要原因如下：

1. 不支持事务：FEDERATED存储引擎不支持事务处理，这意味着在主从复制过程中，如果发生数据修改操作，可能会导致数据不一致或丢失。

2. 性能问题：FEDERATED表在查询时需要将所有满足条件的记录读取到本地再进行处理，这会导致查询速度非常慢。特别是在主从复制中，这种性能瓶颈会进一步放大。

3. 索引问题：如果FEDERATED表中的字段未建立索引，而远程实体表中为此字段建立了索引，性能会非常差。即使后来为虚拟表建立了索引，性能恢复也需要时间，这在主从复制中是不稳定的因素。

4. 主从复制中的宕机风险：在主从复制中使用FEDERATED表时，如果在主库修改此表，可能会引起从库宕机，导致复制中断。

5. 连接和同步问题：FEDERATED存储引擎在跨数据库系统的整合中可能存在连接和同步问题，这在主从复制场景中尤为敏感。

综上所述，FEDERATED存储引擎在主从复制场景中的局限性和潜在风险使其不适合在这种高可用性和数据一致性要求较高的环境中使用。