mysql读写分离
MySQL 数据库读写分离是一种常见的高性能、高可用性架构设计策略，其核心思想是将数据库的写操作（INSERT, UPDATE, DELETE）和读操作（SELECT）分离到不同的数据库服务器（或集群）上进行处理。
主要目标：
提升读性能： 通过将读请求分散到多个只读副本（Slave/Replica）上，显著减轻主库（Master）的负载，提高整体系统的查询吞吐量和响应速度。
提升写性能： 主库可以更专注于处理写操作，避免被大量读请求干扰。
提高可用性：
读操作在从库失败时，通常可以重定向到其他从库或主库（可能牺牲一致性）。
主库失败时，通过故障转移机制可以将一个从库提升为新的主库（需要配合高可用方案如 MHA, InnoDB Cluster, Group Replication 等）。
数据备份与容灾： 从库天然就是主库的一个实时（或近实时）备份，可以用于数据备份、报表生成、数据分析等场景，不影响主库性能。
核心组件与工作原理：
主数据库 (Master)：
唯一处理所有写操作（
INSERT,UPDATE,DELETE,DDL）的节点。将发生的所有数据变更记录到自己的二进制日志 (
Binary Log,binlog) 中。配置：
log-bin=mysql-bin,server-id=1(唯一ID)。从数据库 (Slave/Replica)：
连接到一个或多个主库。
从主库的
binlog中读取变更事件。在本地数据库上重放 (Replay) 这些变更事件（通过 SQL 线程或并行应用），保持与主库数据同步（存在延迟）。
主要处理读操作 (
SELECT)。配置：
server-id=2(唯一且不同于主库)，配置主库连接信息 (CHANGE MASTER TO ...)。数据复制 (Replication)：
异步复制 (Asynchronous Replication - 默认)： 主库提交事务后立即响应客户端，不等待从库确认接收和应用。性能最好，但存在数据丢失风险（主库宕机时未同步的数据）。
半同步复制 (Semi-Synchronous Replication)： 主库提交事务后，至少等待一个从库确认已收到该事务的
binlog事件后才响应客户端。平衡了性能和数据安全性，降低数据丢失风险，但仍可能丢失（如果从库应用前宕机）。组复制 (Group Replication) / InnoDB Cluster： 基于 Paxos 协议的多主/单主同步复制方案，提供强一致性保证和高可用自动故障转移。读写分离通常在其内部实现或通过 Router 实现。
应用层 / 中间件层：
关键角色： 负责识别 SQL 操作是读还是写。
写请求： 路由到主库。
读请求： 路由到可用的从库（一个或多个）。
需要处理：
数据延迟 (Replication Lag)： 从库数据可能落后于主库。应用需要容忍这种延迟，或者对强一致性要求的读操作强制走主库（
SELECT ... FOR UPDATE通常自动走主库，普通SELECT需要框架/中间件支持 Hint 或配置）。负载均衡： 在多个从库之间分发读请求（轮询、权重、基于负载等）。
故障转移： 检测从库故障并移除路由；在主库故障时配合高可用方案切换到新主库。
读写分离不是单纯的数据库方案还是客户端方案，而是数据库负责维护多分数据，而客户端则需要判断业务用主库还是从库，因为绝大多数业务需求是查询数据，所以可以一定限度的突破单服务器的性能限制，分流部分流量到从库。