MySQL 8.4 读写分离怎么避免会话漂移：事务路由、GTID 等待与故障回切

订单刚写入主库，紧接着打开详情页却还是旧状态，这类问题通常不是“副本坏了”，而是同一条用户请求在写入后漂到了还没追上的副本。读写分离真正要管的是事务边界、GTID 位置和连接池里的会话角色；三者少一个，偶发旧读就会在高峰期集中出现。

先把“会话漂移”拆成三个动作

以“修改收货地址后刷新订单页”为例，请求至少会经历写入、提交和读取三个动作。若路由器只按 SQL 是读还是写来分流，写入发到主库，刷新查询就可能落到延迟副本；若连接池复用旧连接，上一笔事务留下的路由状态还会把下一笔请求带偏。

MySQL Router 8.4 的读写分流模型允许一个客户端会话分别使用读写目的地和只读目的地，但应用仍要明确哪些读必须跟随写入。对业务代码来说，最实用的规则是：事务中的读写绑定主库；事务结束后的普通列表查询才允许走副本；写后读则先拿到 GTID，再等待副本具备该位置。

写入后把 GTID 位置带进下一次查询

这里不需要让所有查询都等待。只有会被刚刚写入影响的那一次读取，才携带写事务完成的位置。应用可以把提交后得到的 GTID 放进请求上下文，再选择一个健康副本执行等待。

-- 写连接：事务内完成修改
START TRANSACTION;
UPDATE orders SET address = '杭州西湖区' WHERE id = 1088;
COMMIT;

-- 取出本次提交对应的 GTID 后，在副本连接等待
SELECT WAIT_FOR_EXECUTED_GTID_SET('uuid:1-782', 1);
SELECT id, address FROM orders WHERE id = 1088;

示例中的 GTID 只是演示格式，不能在生产代码里写死。实际服务要从数据库驱动或连接代理拿到当前事务的 GTID 集合，并把它作为一次请求的短期上下文。等待返回超时、连接断开或副本处于不可读状态时，直接把这次读取切回主库；不要继续随机挑另一个副本碰运气。

为什么等待不是万能的同步开关

副本是异步追赶的，等待只保证目标副本已经执行到指定 GTID，不保证业务查询一定走到了这个连接。连接池必须把“等待过的副本连接”和“普通只读连接”分开管理，否则等待完成后连接被归还，下一次借出的连接仍可能来自另一个落后副本。

让事务路由跟着连接状态走

一次事务开始后，路由器或应用连接管理器应把会话标成“主库读写”。事务里的 SELECT 也不能因为是读语句就切到只读连接；锁、临时表、隔离级别和未提交数据都属于当前会话语义。只有 COMMIT 或 ROLLBACK 完成，才允许清除这个标记。

conn = pool.borrow()
try:
    if request.starts_transaction or request.may_write:
        conn.role = "read_write"
    else if request.after_write_gtid:
        conn = replica_pool.borrow_and_wait(request.after_write_gtid)
        if conn.wait_timeout or conn.unhealthy:
            conn = primary_pool.borrow()
    return run(request, conn)
finally:
    conn.reset_transaction()
    conn.clear_route_state()
    pool.release(conn)

“归还前清理”是连接池里最容易漏掉的一步。除了事务状态，还要检查 read_only 观察值、当前库、隔离级别和应用自定义的路由标签。清理失败就销毁连接，别把带着旧状态的连接放回池里。

把延迟和故障回切写成可观测的边界

不要只看副本的连接是否成功。至少记录请求是否刚发生写入、等待的 GTID、等待耗时、目标副本、回主库次数，以及连接归还前的状态清理结果。这样一次旧读才能回答清楚：是副本没追上，还是路由选错，还是连接池复用了错误会话。

• 正常列表查询：只读副本延迟在业务阈值内，且不需要等待。
• 写后读：GTID 等待成功后再查；等待超时则回主库并记录原因。
• 主库切换：停止借出旧主库连接，建立新连接后重新读取 read_only 与角色。
• 恢复阶段：副本重新健康前，不把强一致请求放回普通只读池。

一个可重复的验收顺序

1. 在主库更新订单地址，记录事务 GTID。
2. 立即从普通只读连接查询，确认它可能读到旧值，证明测试能捕捉风险。
3. 从带 GTID 等待的副本连接查询，确认读到新值。
4. 人为增加副本延迟，让等待超时，确认请求回主库而不是返回旧值。
5. 回收连接后重复借出，检查上一笔的主库角色和事务状态没有泄漏。

常见问题

所有读请求都回主库是不是最稳？

它能降低旧读风险，但会牺牲副本的扩展价值。更合适的做法是只让事务读和写后读回主库，其余读请求按延迟和业务容忍度使用副本。

GTID 等待超时后能不能换另一个副本？

可以先重新选择健康副本并再次检查位置，但要有总耗时上限。超过请求预算时直接回主库，不能无限尝试把延迟转嫁给用户。

连接池为什么会让问题变成偶发？

连接池让一次请求留下的事务、隔离级别或路由标签影响下一次请求。借出和归还都做状态核对，才能把“偶尔读旧”变成可复现、可定位的结果。

收尾检查

读写分离的关键不是把查询平均撒到副本，而是让每一次读取都带着它需要的时序语义。主库写入、GTID 等待、事务内固定角色、连接归还清理和故障回切这五个点都能被日志与验收脚本看见，旧读问题才不会靠运气消失。