中间件无法可靠判断主从延迟，因其仅依赖失真的Seconds_Behind_Master，且不感知事务边界与业务上下文；强一致性读必须由业务层显式标记并下沉实现。
不能靠中间件“自动等”或“自动重试”来掩盖主从延迟，它既不感知事务边界，也无法判断某条SELECT是否该读主库——所有所谓“智能路由”都必须由业务层明确传递上下文。
为什么中间件无法可靠判断真实延迟
中间件（如ShardingSphere、MyCat、Atlas）通常只依赖 Seconds_Behind_Master 做路由决策，但这个值在并行复制开启后严重失真：它只反映IO线程和SQL线程之间的时间差，不包含大事务内部的回放耗时。比如主库一个 UPDATE 10万行的事务刚提交，Seconds_Behind_Master 可能已显示 0，但从库SQL线程仍在执行最后几万行，此时中间件若把后续查询发给该从库，必然读到旧数据。
更关键的是，中间件看不到GTID差集、收不到心跳表结果、也不连接从库执行 SELECT NOW(6) - ts FROM heartbeat ——它没有能力做真正贴近业务的延迟测量。
- 所有基于
SHOW SLAVE STATUS的延迟判断，对中间件都是“过期快照”，不是实时状态 - 中间件无法区分“刚写完就查”和“写完5秒后再查”，它没有事务时间戳上下文
- 即使配置了
slave_read_only=false或强制走主库，中间件也做不到按语句级动态降级
中间件能做的有限动作（且需谨慎启用）
中间件唯一可落地的缓解手段，是配合业务层显式标记“强一致性读”，而非试图自动识别。它只能被动响应，不能主动决策：
- 支持 SQL Hint，例如在查询末尾加
/*+ FORCE_MASTER */，中间件解析后强制发往主库 - 允许按逻辑库/表名配置读写分离策略，比如
order_db.order_info全部走主库（适合高频更新+强读场景） - 提供简单的延迟阈值开关：
maxReplicationDelay=500（毫秒），但仅适用于Seconds_Behind_Master尚未失效的单线程复制环境 - 不建议开启“自动重试从库→主库”的兜底逻辑：一次失败后切主库再查，可能破坏事务隔离性，且掩盖了业务本应处理的一致性问题
真正有效的路由逻辑必须下沉到业务代码
中间件只是通道，一致性保障的责任在业务侧。典型做法是让DAO层或服务层决定路由，而不是交给中间件猜：
- 刚插入订单后立刻查详情，调用
orderService.findById(id, ConsistencyLevel.STRONG)，SDK内根据标记走主库 - 用户积分变更后查余额，用
@TargetDataSource(type = DataSourceType.MASTER)显式标注方法 - 消息消费场景（如MQ收到订单创建事件），必须同步查主库——因为消息到达时间和从库同步完成时间完全异步，中间件无法对齐这个时序
- 避免在中间件配置“写后N秒内所有读走主库”的规则：N难定（太小无效，太大伤性能），且无法覆盖跨服务调用链
复杂点在于事务边界与跨服务传播
最容易被忽略的是：一致性要求必须能跨HTTP/gRPC/MQ透传。比如A服务写主库后发MQ，B服务消费时若只查从库，中间件再聪明也救不了。此时必须在消息体里带字段如 "read_consistency": "strong"，B服务收到后主动走主库——这个逻辑无法由中间件自动注入或推断。
同样，分布式事务中（如Seata AT模式），分支事务的读操作若发生在从库，极易因延迟导致脏读或幻读，而中间件对此毫无感知。最终还是得靠业务在 SELECT 前加注解或参数，把一致性意图明确表达出来。
