读写分离通过物理分发读写请求提升性能：主库专注写入避免SELECT干扰，从库水平扩展实现读吞吐线性增长，配合半同步复制与延迟监控保障一致性，主流方案包括云数据库代理、ProxySQL中间件和应用层路由。
MySQL 通过读写分离提升性能，核心是把读请求和写请求物理分发到不同实例上执行，让主库专注写入、从库分担查询压力。这种架构特别适合读多写少的业务场景（比如电商详情页、内容列表、用户中心等），能显著缓解单点瓶颈。
读写分离为什么能提性能
- 主库不再被大量 SELECT 占用连接、CPU 和 I/O，写事务响应更稳定
- 从库可水平扩展（加 1 台、3 台甚至更多），读吞吐量基本线性增长
- 复杂查询、报表统计等耗资源操作可定向路由到专用从库，不影响主库
关键前提是主从数据同步可靠
- 必须开启 binlog（推荐 ROW 格式），配置 server-id，建立主从复制链路
- 建议启用半同步复制（semi-sync），避免主库提交后从库还没收到就返回成功，降低延迟风险
- 监控复制延迟（Seconds_Behind_Master），超过阈值时可临时将部分读请求切回主库
主流实现方式对比选型
- 数据库代理层（推荐云环境）：如阿里云数据库代理、腾讯云 DBProxy。无需改代码，只需把应用连接地址换成代理地址，自动识别 SELECT / INSERT 等语句并路由。支持权重分配、故障自动摘除、连接池复用。
-
中间件方案（推荐自建集群）：如 ProxySQL。灵活性高，可定制规则（例如
SELECT ... FOR UPDATE强制走主库，普通SELECT走从库组），还支持查询缓存、慢 SQL 拦截、动态权重调整。 - 应用层路由（适合微服务或框架可控场景）：Spring Boot + AbstractRoutingDataSource + 自定义注解（如 @ReadOnly）。由代码控制数据源切换，完全自主但耦合度高，需统一管理多个数据源配置和健康检查逻辑。
实际效果参考
某中型电商平台在接入 2 台只读从库 + 数据库代理后：
- 主库 CPU 使用率从 85% 降至 42%
- 平均查询响应时间缩短 58%
- 大促期间读 QPS 提升近 3 倍，未出现连接打满或超时
本质上，读写分离不是“魔法”，而是把原本挤在一台机器上的压力，合理拆解到多台机器上。只要主从同步不掉队、路由策略不误判、监控告警跟得上，就能稳定释放性能红利。
