mysql并发下读写分离是否有效_mysql架构原理解析_技术教程

读写分离仅在读多写少、主从延迟可控、接受弱一致性时有效；主从延迟会导致脏读；事务内读、强一致查询、锁读、跨库JOIN必须走主库；中间件透明但缺乏上下文感知，应用层灵活但需处理异步场景一致性。

读写分离在 MySQL 并发场景下是否真能提升性能

不能一概而论。读写分离只有在读多写少、主从延迟可控、业务能接受弱一致性的前提下才有效。高并发写入密集型场景（如秒杀扣库存、高频日志写入）下，强行读写分离反而会因主从同步延迟导致脏读，或因路由逻辑增加额外开销。

MySQL 主从复制延迟如何影响读写分离效果

主从延迟是读写分离失效的最常见原因。一旦 Seconds_Behind_Master 持续大于 0，所有发往从库的 SELECT 都可能读到过期数据。尤其在以下情况中风险突出：

大事务提交后，从库需重放 binlog，延迟可能达秒级甚至分钟级
从库配置低于主库（如磁盘 I/O 更慢、CPU 核数更少）
开启了 read_only=1 但未设置 super_read_only=1，导致从库被误写，进一步破坏数据一致性
应用未做 SELECT 路由兜底——比如用户刚下单（写主库），立刻查订单列表（可能路由到从库），结果查不到

哪些查询必须强制走主库

不是所有读操作都适合下推到从库。以下几类 SELECT 必须直连主库，否则逻辑错误：

事务内后续读：在 BEGIN → INSERT/UPDATE → SELECT 流程中，该 SELECT 必须看到刚写的变更
依赖最新状态的判断逻辑：例如 SELECT COUNT(*) FROM orders WHERE status = 'pending' 用于触发补单任务，延迟会导致漏处理
涉及 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 的语句——从库不支持写锁，执行会直接报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option
跨库关联查询（如 JOIN 主库 db1 和从库 db2 的表）——架构上无法支持，必须统一走主库

中间件 vs 应用层实现读写分离的取舍

选择实现方式直接影响稳定性与可控性：

用 ShardingSphere-JDBC 或 MyCat 等中间件：配置简单，对应用透明，但版本升级易引发 SQL 兼容问题；且无法感知业务上下文（比如无法自动识别“刚写完就查”这种场景）
在应用层用 AbstractRoutingDataSource（Spring）或自定义 DBConnectionPool 控制路由：可结合 ThreadLocal 记录写标记，实现“本请求内后续读走主库”，灵活性高；但需团队具备数据库连接治理能力，且容易在异步线程（如 @Async、线程池）中丢失上下文
完全不用中间件/框架，靠 DNS 或 VIP 切换：仅适用于读写流量物理隔离的极简场景，无法解决单请求内的强一致性需求

if (isWriteInThisRequest.get()) {
    return "master";
} else if (isInTransaction.get()) {
    return "master";
} else {
    return roundRobinSlave();
}

上面这段路由逻辑看似合理，但要注意：isWriteInThisRequest 在 WebFlux 或 CompletableFuture 链路中极易失效；isInTransaction 若用 Spring 的 TransactionSynchronizationManager，需确认传播行为是 REQUIRED 而非 REQUIRES_NEW，否则嵌套事务里会误判。

真正难的不是配通读写分离，而是厘清每条 SQL 的一致性边界，并让路由策略在各种调用