MySQL读写分离是围绕“主库写、从库读”构建的协同机制，依赖主从复制实现数据同步，并通过中间件或应用层路由分发请求；它适用于读多写少场景，需接受最终一致性，且强一致读必须直连主库。
MySQL 读写分离不是简单地把 SELECT 和 INSERT 拆开，而是围绕“主库写、从库读”构建的一套协同机制，核心依赖主从复制的稳定性，并通过中间件或代码层实现请求路由。它解决的是读多写少场景下的资源争用与单点压力问题，不是万能方案，但对中大型应用是性价比极高的优化路径。
主从复制是读写分离的前提
没有可靠的数据同步，读写分离就失去意义。主库开启 binlog，从库通过 I/O 线程拉取日志、SQL 线程重放变更，整个过程异步进行。这意味着从库数据天然存在延迟——可能几毫秒，也可能数秒，取决于网络、负载和事务大小。业务必须接受“最终一致性”，不能假设刚写入的数据立刻可读。
- 务必验证主从状态：在从库执行 SHOW SLAVE STATUS\G，确认 Seconds_Behind_Master = 0（或稳定小值）且 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes
- 主从账号需独立创建，权限最小化。例如只给 mycat_rw 账号授予 SELECT, INSERT, UPDATE, DELETE, REPLICATION SLAVE 权限，禁用 root 直连
- 建议开启 GTID 模式，避免传统 position 同步中断后难以定位的问题，提升切换与恢复的可靠性
中间件选型要匹配实际需求
中间件不是越重越好，关键看运维能力、功能边界和协议兼容性。MyCAT、ProxySQL、MaxScale 都支持 SQL 层路由，但策略粒度和扩展性差异明显。
- MyCAT 适合需要分库分表+读写分离一体化的场景，配置以 XML 或动态 SQL 为主，对 Java 生态友好；但学习成本略高，新版本社区活跃度需关注
- ProxySQL 规则引擎强大，支持正则匹配、权重轮询、自动故障剔除，还能缓存查询结果；适合对读负载均衡精度要求高、且已有 DBA 熟悉 SQL 运维的团队
- MaxScale 由 MariaDB 官方维护，协议解析稳健，内置监控模块和 CLI 工具，适合偏好官方支持、重视稳定性的生产环境
- 若仅需基础路由且希望轻量部署，MySQL Router 是官方推荐选项，但不支持读写权重调节或复杂规则
路由策略必须兼顾一致性与性能
不是所有 SELECT 都该走从库。强一致读（如订单详情页刚提交后的跳转）、管理后台实时统计等场景，必须直连主库，否则会看到过期数据。
- 可在中间件中设置例外规则：例如匹配 SELECT ... FOR UPDATE 或含特定注释（如 /*+ MASTER */）的语句强制发往主库
- 从库节点应配置健康检查（如心跳探针），自动下线异常实例，避免请求打到已断连的从库上
- 若有多台从库，建议启用权重配置而非纯轮询，例如将性能更强的从库权重设为 3，其余设为 1，更合理分摊压力
上线前必须做真实流量验证
配置完成不等于可用。需模拟线上行为，验证路由准确性、延迟容忍度和故障响应能力。
- 用 mysql -h MyCAT_IP -P 8066 -u user -p 连接中间件，执行 SELECT @@server_id;，确认读请求返回的是从库 server_id，写请求返回的是主库 server_id
- 人工制造主库延迟（如暂停从库 SQL 线程），观察中间件是否仍把读请求发往延迟节点；如有必要，启用延迟阈值自动隔离（如 ProxySQL 的 max_replication_lag）
- 模拟主库宕机，验证是否触发自动切换（部分中间件支持）、应用连接是否快速重连、从库是否升主成功且写流量可承接
