MySQL主从复制依靠binlog异步日志重放机制，主库COMMIT后写binlog，从库通过IO Thread拉取至relay log，再由SQL Thread串行回放，故延迟不可避免。
MySQL主从复制靠的是什么机制
主从复制本质是基于 binlog 的异步日志重放，不是实时同步，也不是共享存储。主库写入 COMMIT 后才写 binlog，从库的 IO Thread 拉取 binlog 到本地 relay log，再由 SQL Thread 串行回放——这意味着从库延迟不可避免，尤其在大事务、高并发写入或网络抖动时。
常见误区是认为“开了 GTID 就一定强一致”，其实 GTID 只解决位点定位问题，不改变异步复制的本质；semi-sync 插件能提升可靠性，但会增加主库响应时间，且仍可能退化为异步（超时后）。
读写分离中间件怎么判断读请求能不能走从库
多数 Java 应用用 ShardingSphere-JDBC 或 MyBatis-Plus 多数据源做读写分离，它们靠 SQL 解析 + 上下文标记来路由。关键点在于：不是所有 SELECT 都能走从库。
-
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE必须走主库，否则会报错或锁失效 - 事务内第一个 SQL 是写操作（
INSERT/UPDATE/DELETE），后续的读默认也走主库，避免幻读或查不到刚写的记录 - 显式调用
Hint（如 ShardingSphere 的/* sharding hint: write */）可强制走主库 - 某些框架（如 Druid）支持
TransactionIsolation级别检测，但无法识别逻辑上的“强一致性读”需求，比如“查我刚刚下单的订单状态”
Java 应用里配置主从数据源容易漏掉什么
Spring Boot + MyBatis 多数据源配置时，最容易被忽略的是事务传播与连接生命周期绑定问题：
立即学习“Java免费学习笔记（深入）”；
- 没给
@Transactional显式指定transactionManager，导致事务只作用于主数据源，从库操作游离在外 - 手动获取
Connection或使用JdbcTemplate时绕过了数据源路由逻辑，直接连了主库或固定某一个库 - Druid 连接池的
initVariants或initConnectionSqls若含写语句（如SET NAMES utf8mb4），可能触发主库连接初始化失败（因从库只读） - 健康检查 SQL（如
SELECT 1）若发到从库，需确保从库未启用read_only=1以外的限制（例如某些云数据库禁用SELECT在只读实例上执行非查询语句）
面试官常追问的复制延迟应对策略
当被问“如何解决主从延迟导致读到旧数据”，不要只答“加缓存”或“强制读主库”。真实系统中更可行的是分层控制：
- 对用户无感知的场景（如后台报表），接受秒级延迟，不做干预
- 对“自己刚提交的数据必须立刻可见”，用
ThreadLocal记录本次请求是否发生过写操作，后续读自动路由到主库（ShardingSphere 支持MasterSlaveDataSource的hint方式） - 对“别人刚提交的数据需要及时看到”，引入消息队列通知缓存失效，或用
binlog + Canal监听变更后主动刷新本地状态 - 极端一致性要求（如金融转账余额查询），放弃读写分离，统一走主库——这不是设计缺陷，而是权衡
真正难的不是知道这些方案，而是在简历里写了“实现过读写分离”，却说不清自己项目里 max_replication_delay 设了多少、监控看哪个指标（Seconds_Behind_Master）、出问题时怎么快速切流量。
