读写分离不直接缩短单次响应时间，而是通过分流读压力、释放主库资源来提升整体响应稳定性；需避免读压垮主库或从库延迟引发重试，关键措施包括主库减负、从库提速、智能路由及缓存协同。
读写分离本身不直接缩短单次请求的响应时间，而是通过分流读压力、释放主库资源，间接让整体系统的平均响应更稳定、更可预期。关键在于避免“读请求压垮主库”或“从库延迟导致反复重试”，这两点才是拖慢真实响应的元凶。
主库减负：让写操作更快完成
主库响应慢，往往不是因为SQL本身慢，而是被大量读请求挤占了CPU、内存和IO带宽。一旦写请求排队，就会出现连接超时或事务等待。
- 确保所有非必要读请求（如报表查询、后台统计、列表页）全部路由到从库，主库只处理写入和强一致性读（比如刚下单立刻查订单状态）
- 检查应用层是否误将读SQL发往主库——常见于未正确配置中间件（如ShardingSphere、MyCat）或手动拼接SQL时忽略读写标记
- 对主库开启半同步复制（semisync），避免因从库堆积导致主库binlog刷盘阻塞，这能缓解部分写延迟
从库提速：缩短读请求的实际等待时间
从库响应快 ≠ 数据新。如果客户端读到的是延迟1秒的旧数据，再快也没意义；而为等数据同步又主动加sleep或重试，反而拉长了端到端耗时。
- 升级MySQL 5.7+并启用多线程复制（slave_parallel_workers > 0），尤其对多表并发更新场景，能显著降低relay log回放延迟
- 将热点从库部署在同一内网低延迟区域，避免跨机房同步带来的网络抖动；主从间专线带宽不低于写入峰值的1.5倍
- 对延迟敏感的读请求（如用户中心、支付结果页），可设置“主库强读”开关——即该请求绕过读写分离规则，直连主库获取最新态
请求路由：不让慢节点拖累整体体验
负载均衡策略不能只看机器在线与否，还要感知实时延迟。一个延迟3秒的从库如果持续接收请求，会把整个读链路拖慢。
- 中间件或SDK应集成主从延迟监控（Seconds_Behind_Master），自动剔除延迟超过阈值（如500ms）的从库
- 避免轮询式分发，改用加权随机或最小连接数算法，优先将请求打向延迟低、负载轻的从库
- 对高QPS接口做读请求降级预案——例如当所有从库延迟均超1s时，自动切回主库读（需配合熔断机制防雪崩）
缓存协同：减少穿透到数据库的读流量
读写分离解决的是“数据库层分流”，但最高效的读，其实是“根本不查库”。缓存是读写分离的最佳搭档。
- 写操作成功后，主动失效（invalidate）对应缓存key，而非仅依赖过期，避免从库延迟期间缓存与DB不一致
- 对频繁读、少修改的数据（如商品类目、用户等级配置），用本地缓存（Caffeine）+分布式缓存（Redis）两级结构，进一步降低从库QPS
- 缓存穿透场景下（如恶意ID查询），用布隆过滤器拦截无效请求，防止击穿从库造成雪崩
