嵌套查询在双主架构下查不到刚写入的数据，根本原因是查询被路由到尚未同步写入数据的主库，而非SQL语法或逻辑错误；双主异步复制导致B主库子查询基于旧快照执行，即使Seconds_Behind_Master显示为0，binlog也可能未应用完。
嵌套查询在双主架构下为什么查不到刚写入的数据
不是语法错，也不是SQL写得有问题，而是你发出去的那条 SELECT ... WHERE id IN (SELECT ...) 被路由到了还没同步完的那台主库上。双主之间靠异步复制，Seconds_Behind_Master 在另一台主库上可能显示为 0，但实际 binlog 还没应用完——尤其当写入发生在 A 主库、查询落在 B 主库时，B 上子查询看到的是旧快照。
- 典型现象：
NOT IN返回空结果，但手动连 A 主库执行子查询能查到数据 - 更隐蔽的情况：子查询里用了
UUID()或NOW()，中间件（如 ShardingSphere）直接拒绝路由到只读节点，却没 fallback 到“当前写入所在主库”，而是随机选了另一台主库执行，导致逻辑错乱 - 如果双主启用了 GTID 但
gtid_mode=OFF，或enforce_gtid_consistency=OFF，跨库事务可能被拆成多个不连续的 event，子查询执行时刚好卡在中间状态
怎么让嵌套查询落到正确的主库实例上
靠数据库自己识别“这个查询依赖刚才的写”是不可靠的，必须由应用层或中间件明确控制路由。MySQL 自身没有跨库事务一致性保障，双主也不提供会话级读己之所写（read-your-write）语义。
- 强制走写库：在 SQL 注释里加
/*+ FORCE_MASTER */（ShardingSphere 支持），或用hint如/*FORCE_SLAVE=0*/（某些 Proxy 实现） - 绑定会话：开启事务后，所有嵌套查询自动继承事务起点的连接；但注意
REQUIRES_NEW会新开事务并脱离原连接，必须显式传参指定masterRoute=true - 避免隐式路由：不要依赖
SET SESSION TRANSACTION READ ONLY来触发从库路由——双主下它可能把你导到延迟更高的那台
子查询里调用 volatile 函数的风险
CURRENT_TIMESTAMP、UUID()、NOW() 这类函数在双主架构下不只是“结果不同”，而是会导致路由决策失败或执行报错。PostgreSQL 从库默认禁用 CURRENT_TIMESTAMP，MySQL 8.0+ 的 READ ONLY 模式也会拒绝执行。
- 错误信息常见：
ERROR 1792 (HY000): Cannot execute statement in a read-only transaction - 真正的问题是：中间件检测到 volatile 函数后，本该 fallback 到主库，但若配置了双主负载均衡策略，可能 fallback 到“非写入源”的那台主库，造成数据视图不一致
- 安全做法：把时间戳、ID 等值由应用层生成并作为参数传入，子查询改写为
WHERE created_at > ?而非WHERE created_at > NOW()
为什么 DERIVED 表物化会让问题更糟
当 MySQL 优化器对子查询选择 type=DERIVED（即先物化成临时表再关联），在双主环境下等于把“过期快照”固化了一次。比如主库刚插入用户 A，B 主库还没同步，子查询物化出空临时表，外层 JOIN 就永远找不到 A 的订单——即使后续 B 库追平了延迟，这个查询结果也不会变。
- 确认方式：在目标主库上
EXPLAIN FORMAT=TREE查看是否出现<derived>节点 - 规避手段：加
STRAIGHT_JOIN强制驱动表顺序；或用JOIN重写子查询，避免优化器物化决策 - 更彻底的解法：把子查询提前执行、结果缓存在应用内存里，外层 SQL 改用
IN (1,2,3...)字面量，绕过运行时物化
