MySQL读写分离是依赖主从复制的架构策略，将写操作发往主库、读操作分发至从库以分摊负载；必须确保主从延迟在业务可接受范围内，并根据新老系统特点选择中间件代理或应用层路由方案。
MySQL读写分离不是 MySQL 自带的功能，而是一种架构设计策略：把 INSERT、UPDATE、DELETE 等写操作固定发给主库（Master），把 SELECT 等读操作尽量分发到一个或多个从库（Slave）。它的前提和基础是 MySQL 主从复制——没有数据同步，读写分离就毫无意义。
这个策略解决的不是“能不能用”，而是“扛不扛得住”：当你的应用每秒有上千次查询、但写入只有几十次时，硬让主库同时扛读+写，锁争用、IO 压力、连接数瓶颈会迅速暴露。读写分离本质是用多台机器分摊负载，拿硬件换并发能力。
为什么必须先搭好主从复制？
因为读写分离的“读”如果落到从库，而从库数据是旧的，业务就可能出错。比如用户刚注册（写入主库），立刻刷新页面查个人信息（读从库），结果查不到——这就是典型的 主从延迟导致的一致性问题。
- 主从同步靠的是主库的
binlog+ 从库的I/O thread和SQL thread，整个过程默认是异步的，延迟几毫秒到几秒都常见 -
show slave status\G中的Seconds_Behind_Master是关键指标，>0 就说明有延迟 - 不能只看同步是否“成功”，更要监控延迟是否在业务可接受范围内（比如订单类系统通常要求 ≤ 100ms）
中间件代理 vs 应用层路由：选哪个？
这是落地时最常纠结的点。两者不是优劣关系，而是适用场景不同：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
中间件代理（如
ProxySQL、ShardingSphere-Proxy、已停更但仍有遗留使用的Amoeba）：应用完全无感，所有连接指向代理地址；适合已有老系统、不想改代码、DBA 主导运维的场景；但多一层网络跳转，故障点增加，且代理自身需高可用 -
应用层路由（如
MyBatis多数据源 +@DS注解、Sharding-JDBC）：代码里显式指定读/写数据源；性能略好、链路更短；但侵入性强，事务中混用读写容易踩坑（比如SELECT ... FOR UPDATE必须走主库）
新项目建议优先考虑 Sharding-JDBC 或框架原生支持（如 Spring Boot 的 AbstractRoutingDataSource），老系统升级建议上 ProxySQL——它支持 SQL 拦截、自动故障剔除、流量镜像，比写死在代码里的方案更可控。
哪些 SELECT 不能随便扔给从库？
不是所有读操作都适合走从库。以下情况必须强制走主库，否则会破坏业务逻辑：
- 事务内后续的
SELECT（尤其涉及SELECT ... FOR UPDATE或依赖刚写入的数据） - 刚执行完
INSERT/UPDATE后立即SELECT（即“写后读”，例如注册后查用户 ID） - 对强一致性敏感的查询，比如资金余额、库存扣减后的校验
- 使用了
GET_LOCK()、SELECT @@last_insert_id等依赖主库会话状态的函数
实际做法不是“全量禁止”，而是通过会话级标记（如 /*FORCE_MASTER*/ 注释）、线程本地变量（ThreadLocal）或上下文传播，在关键路径上绕过读写分离逻辑。
真正难的从来不是配置几个 slave 或启动一个 ProxySQL，而是判断哪条 SQL 该走哪条路、延迟到什么程度要降级、事务边界怎么守得住。这些没法靠文档自动解决，得结合日志、监控、压测反复调——尤其是上线前，一定要用真实流量做 read-after-write 场景验证。
