读请求走从库拿到旧数据主因是从库复制延迟高而路由未规避，proxysql需用脚本动态更新mysql_servers中weight值来剔除高延迟节点，应用层应按一致性要求分级路由并配合心跳表检测真实延迟。

为什么读请求走从库还会拿到旧数据

根本不是“路由没配对”，而是从库 Seconds_Behind_Master 已经涨到几秒甚至几分钟，但你的路由逻辑仍把它当健康节点用。常见表现是：用户刚下单，刷新订单页就查不到；库存扣减后立刻查剩余量，返回旧值。这说明路由层没感知延迟，或感知了但没做决策干预。

ProxySQL 中如何动态避开高延迟从库

ProxySQL 自带 mysql_servers 表和 monitor 模块，但默认只检查端口连通性，不查复制延迟。必须手动注入延迟检测逻辑：

• 在 mysql_servers 表中为每个从库配置 weight，初始设为 1000
• 写一个定时脚本（如每 2 秒执行一次），连接每个从库执行 SHOW SLAVE STATUS，提取 Seconds_Behind_Master
• 若延迟 > 3 秒，更新该从库的 weight 为 0；恢复时再设回 1000
• 确保 mysql_query_rules 的 destination_hostgroup 指向含多个从库的 hostgroup，且启用 load_balance_mode=1

注意：weight=0 不等于下线——它只是让 ProxySQL 在负载均衡时跳过该节点，不发任何流量过去，比单纯 kill 连接更轻量、更可控。

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

应用层路由绕过 ProxySQL 时的关键判断点

如果用代码（如 Spring Boot + AbstractRoutingDataSource）做路由，不能只靠 SQL 类型（SELECT / UPDATE）分流。必须叠加延迟感知：

• 缓存每个从库最近一次的 Seconds_Behind_Master 值，TTL 设为 5 秒（避免频繁查库）
• 对强一致性读（如“我的订单”“账户余额”），直接走主库，不走任何从库
• 对普通读（如商品列表、文章详情），优先选 Seconds_Behind_Master ≤ 1 的从库；若全部 > 3，则 fallback 到主库，而非报错或空结果
• 避免在事务内混用主从：一个事务里先写主库，再读从库，大概率读到旧数据

延迟监控本身不能解决路由问题，但能暴露设计缺陷

Seconds_Behind_Master 是个“事后指标”，它反映的是过去已发生的延迟，不是未来预测值。很多团队花大力气搭 Grafana 看这个数，却忽略真正要动的是路由策略。更危险的是：当从库 SQL 线程卡死时，Seconds_Behind_Master 可能卡在 0 不动（因为没新 binlog 可比），但实际已完全不同步。所以生产环境必须配合 pt-heartbeat 或自建心跳表做真实延迟探测。