SQL视图不参与读写分离路由，其执行节点由连接的只读属性、函数稳定性及复制完整性共同决定；任一不满足即静默退至主库执行。
SQL 视图本身不参与读写分离路由，它只是语法封装，不会自动把 SELECT 转发到从库——这个动作必须由连接层、中间件或应用代码显式控制。
视图查询为什么总在主库执行
常见现象是：明明配置了 MyCat 或 ShardingSphere，但 SELECT * FROM user_view 依然打到主库。根本原因不是视图写得不对，而是数据库连接未声明只读语义。
- MySQL 客户端连接需显式设置
read_only=1（或通过SET SESSION read_only = 1），否则中间件无法识别该连接可路由至从库 - PostgreSQL 更推荐在会话级执行
SET default_transaction_read_only = on，比单纯用只读用户更可靠——某些含NOW()、RANDOM()的视图可能绕过用户权限检查，但逃不过事务只读标记 - 若使用连接池（如 HikariCP），需确认其
connection-init-sql配置已注入只读指令，否则每次新连接都是默认可写状态
含 volatile 函数的视图无法路由到从库
当视图定义里出现 NOW()、UUID()、RANDOM()、USER() 等 volatile 函数时，多数中间件（如 ProxySQL、ShardingSphere）会直接拒绝将其下推到从库，降级走主库执行。
- 这是安全策略，不是 bug：从库数据本就存在延迟，再叠加非确定性函数，结果不可预期
- 解决方法不是“禁用函数”，而是拆分逻辑——把 volatile 计算移到应用层，视图只做纯数据聚合；或改用
SYSDATE()（MySQL）这类受复制上下文约束的替代函数（需验证 binlog_format 兼容性） - PostgreSQL 中
CURRENT_TIMESTAMP是 stable 函数，可安全用于从库；但clock_timestamp()是 volatile，同样触发主库降级
多表 JOIN 视图在从库返回空或错乱结果
不是同步延迟导致的“旧数据”，而是从库漏同步了某张被 JOIN 的表——典型表现是 SELECT COUNT(*) FROM order_detail_view 在从库返回 0，而主库有上万条。
- 检查
SHOW SLAVE STATUS\G中的Replicate_Ignore_Table或replicate-wild-ignore-table配置，确认是否误加了通配规则（如%temp%意外匹配了order_temp） - MySQL 8.0+ 开启
slave_preserve_commit_order=ON可缓解多线程复制下因表间依赖导致的短暂数据断裂，避免视图 JOIN 时出现“半同步”状态 - 若视图跨库（
db1.t1 JOIN db2.t2），需确保两个库都在从库上完整存在且未被过滤——单库复制配置不等于全实例同步
PostgreSQL 流复制下视图“查不到最新数据”的真实原因
即使 pg_stat_replication 显示 sync_state = sync 且延迟为 0，视图结果仍可能滞后——这不是复制问题，而是快照隔离（SI）机制决定的。
- 每个从库查询都基于启动瞬间的事务快照，刚在主库提交的数据，除非新起一个查询连接，否则不会出现在当前事务中
- 不能靠
SELECT pg_sleep(0.1)来“等数据”，必须重建连接或显式开启新事务（BEGIN READ ONLY）才能获取更新后的快照 - 若业务要求强一致性视图，应避免依赖从库，或改用逻辑复制 +
pg_logical_slot_get_changes做应用层补偿，而非指望视图自动同步
最易被忽略的一点：视图能否参与读写分离，和它是否“看起来像只读”完全无关，只取决于连接属性、函数稳定性、复制完整性这三者是否同时满足。缺一不可，少一个就会静默退回到主库执行。
