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 应用层路由：选哪个？
这是落地时最常纠结的点。两者不是优劣关系，而是适用场景不同：
中间件代理（如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场景验证。
