create view不能解决主从读写分离，因其仅封装单库select、不参与路由决策、不感知主从连接状态；真正起作用的是连接池、驱动或中间件的读写分发逻辑。
视图无法屏蔽主从架构的底层细节，它不参与路由、不感知连接状态、也不切换执行节点——所有查询仍发往当前连接的数据库实例。所谓“屏蔽”，只能靠中间层或应用逻辑实现，视图最多起命名统一作用。
为什么 CREATE VIEW 不能解决主从读写分离
主从架构的核心是请求分发：写操作必须打到主库，读操作可打到从库。而视图只是对单个数据库内的一条 SELECT 封装，它完全不知道自己运行在主还是从。你建一个 v_user_summary，在主库上查和在从库上查，用的是同一份定义，但延迟、一致性、甚至是否能查到最新数据，全取决于连接池把这条语句发到了哪台机器。
常见错误现象：
- 应用连着从库查
v_user_summary，却因从库延迟看不到刚插入的用户 - 开发误以为“用了视图就自动读从库”，结果所有读请求压在主库，主库 CPU 拉满
- 视图里用了
NOW()或LAST_INSERT_ID()这类会话相关函数，在从库上行为异常
真正起作用的是连接层配置，不是视图定义
要让应用无感地走主从，关键在驱动、连接池或代理层，而不是 SQL 结构本身：
- MySQL JDBC 驱动支持
loadBalance或replication模式，配合readFromMasterWhenNoSlaves=true等参数控制读写路由 - PostgreSQL 的
pgbouncer或pgpool-II可基于 SQL 类型（是否含 INSERT/UPDATE）自动分发 - 应用框架如 Spring Boot 的
@Transactional(readOnly = true)可触发多数据源路由，视图名在这里只是普通表名，不参与决策 - 如果硬要用视图做“统一入口”，那所有环境（开发/测试/生产）必须确保连接池配置一致，否则
SELECT * FROM v_orders在本地连主库，在线上连从库，结果就不一致
视图唯一能做的：收敛 SQL 写法，降低切换成本
当你要从单库切到主从架构时，视图能减少应用改代码量，但前提是已有严格约束：
- 所有应用 SQL 必须只查视图（如
v_user），严禁直写users表名；否则加了从库后，那些硬编码的SELECT * FROM users依然全打主库 - 视图定义必须禁用非确定性函数：
SYSDATE、RAND()、UUID()等在从库可能报错或返回不同值 - 避免在视图里写
FOR UPDATE或LOCK IN SHARE MODE—— 这些语句强制走主库，会破坏读写分离效果 - MySQL 下尤其注意：视图若含子查询或聚合，从库上执行计划可能退化，
EXPLAIN显示ALL扫描，此时不如直接查基表+加索引
最容易被忽略的一点：主从延迟导致的视图结果不一致，不会报错，只会静默返回旧数据。监控不能只看 QPS 和延迟毫秒数，得在业务层埋点比对 v_user 和直查 users 的结果差异——这才是真实影响。
