开启读写分离后，事务内的读请求也会自动转发至 Follower 节点。——判断题
1 个赞
错误。
开启读写分离后，事务内的读请求不会自动转发至 Follower 节点，而是会被路由到主节点（Leader/Primary）。这是主流数据库和中间件的通用设计原则，原因如下：
核心原因：保证事务一致性
事务内的读操作如果路由到 Follower 节点，可能因为主从复制延迟（replication lag）而读取到过期数据，破坏事务的隔离性和一致性。例如，事务内先 INSERT 一条数据，紧接着 SELECT 查询，如果 SELECT 被路由到尚未同步完成的从库，就会查不到刚插入的数据。
各主流平台的实际行为
- 阿里云 PolarDB：明确说明"事务中的请求都路由到主节点，事务退出后，恢复负载均衡"
- PolarDB for MySQL：事务关闭时的所有事务请求仅转发到主节点
- UCloud UDB：事务只能被路由到主节点，因此如果业务 SQL 全部包含在事务中，读写分离无法起到分离读请求的作用
- ProxySQL：开启事务时，会自动把所有请求路由到同一个 hostgroup（即事务开始时所在的主库）
- Symfony/Doctrine：事务内所有查询强制走主库，replica 连接进入事务会报错
正确理解
读写分离的路由规则通常是：
- 非事务性读请求（普通 SELECT）→ 可转发至 Follower 节点
- 事务内的所有请求（包括读）→ 强制路由到主节点
- 写操作（INSERT/UPDATE/DELETE）→ 路由到主节点
因此，题干的说法是错误的。