在高并发场景下，MySQL 的读写分离是一种常见且有效的性能优化手段。通过将读操作分发到从库（Slave），写操作集中在主库（Master），可以减轻主库压力，提升整体系统的吞吐能力。
1. 读写分离的基本原理
MySQL 主从复制是读写分离的基础。主库负责处理所有写请求（INSERT、UPDATE、DELETE），并通过 binlog 将数据变更同步到一个或多个从库。从库只负责处理读请求（SELECT），从而实现负载分散。
关键点：
主从数据异步复制，存在极短延迟 读写操作必须正确路由：写走主，读走从 应用层或中间件需具备读写分离逻辑2. 实现方式选择
常见的读写分离实现方式有三种，可根据业务复杂度和技术栈选择：
应用层实现在代码中手动控制数据库连接。例如使用连接池配置多个数据源，根据 SQL 类型选择主库或从库连接。
优点：灵活，可精细控制 缺点：开发成本高，容易出错 适合：中小型项目或已有架构改造 中间件代理使用如 MyCat、ShardingSphere-Proxy 或 MaxScale 等中间件，自动解析 SQL 并路由。
优点：对应用透明，支持自动故障转移 缺点：增加系统层级，需维护中间件 适合：中大型系统，追求解耦 JDBC 驱动支持使用 MySQL 官方 Connector/J 提供的 loadBalance 套件或 replication 连接模式。
示例连接字符串：
jdbc:mysql:replication://master_ip:3306,slave_ip:3306/dbname?allowMasterDownConnections=true
自动识别 read-only 属性决定连接目标 结合 Spring 可通过 @Transactional(readOnly = true) 自动路由3. 注意事项与挑战
读写分离并非银弹，需注意以下问题：
主从延迟：刚写入的数据可能在从库查不到，影响一致性。关键查询可强制走主库 事务中的读操作：事务内所有操作应统一走主库，避免读到旧数据 从库扩容：增加从库可提升读能力，但主库仍为单点瓶颈 监控与切换：需监控主从延迟、从库状态，异常时及时告警或降级4. 实际优化建议
要真正发挥读写分离效果，还需配合其他策略：
合理设置从库数量，避免过多影响主库复制性能 读多写少的表优先实施分离，比如日志、商品信息等 结合缓存（如 Redis）进一步降低数据库读压力 定期检查主从延迟，设置 max_allowed_delay 告警阈值基本上就这些。读写分离能显著提升 MySQL 的并发处理能力，但需要结合业务特点设计路由策略，并关注数据一致性问题。架构上越早规划，后期扩展越顺畅。不复杂但容易忽略细节。
