主库创建的视图未同步到从库，根本原因是binlog_format=row模式不记录ddl操作；需手动在从库执行show create view获取定义并建视图，且应将视图纳入版本化部署流程。
从库没同步主库创建的视图，先确认是否启用了 binlog_format=STATEMENT
MySQL 默认在 binlog_format=ROW 模式下，不会记录视图、存储过程、函数、事件等 DDL 操作——只记录行级变更。所以即使主库执行了 CREATE VIEW，从库也不会自动创建该视图。
常见现象是：主库能查到视图，从库执行 SHOW CREATE VIEW xxx 报错 Table 'xxx' doesn't exist，或直接查询报 Unknown table。
- 检查主库当前格式：
SELECT @@binlog_format; - 若返回
ROW，这就是根本原因；STATEMENT或MIXED才可能记录视图创建语句（但MIXED实际也常退化为ROW） -
ROW模式更安全、更常用，不建议为视图临时切回STATEMENT，容易引发其他复制风险
手动在从库创建视图是最稳妥的解决方式
视图本质是查询定义，不存数据，也不参与事务，因此无需“同步”，只需保证定义一致。跳过复制、手动补建即可。
- 在主库导出视图定义：
SHOW CREATE VIEW your_view_nameG，复制Create View后面的完整 SQL - 登录从库，粘贴执行（注意校验数据库名、表名、字段名是否存在且大小写匹配）
- 若视图依赖的基表在从库缺失或结构不一致，需先修复表结构，否则建视图会失败
- 批量处理可用脚本提取所有视图：
SELECT CONCAT('SHOW CREATE VIEW ', table_schema, '.', table_name, '\G') FROM information_schema.views WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema');
为什么不能靠跳过错误或重放 relay log 来恢复视图
因为视图不是由 binlog 事件“触发”的，它压根没进 relay log。即使你执行 SET GLOBAL sql_slave_skip_counter = 1 或用 mysqlbinlog 解析主库 binlog，也找不到对应事件。
-
SHOW SLAVE STATUSG中的Last_Error不会报视图相关错误（无错误可报） -
Seconds_Behind_Master可能正常，但视图就是没有——这是静默缺失，不是同步中断 - 试图用
pt-table-sync或mysqldump --no-data补结构也无法还原视图，它们不处理 view 对象
长期预防：把视图纳入部署流程，而非依赖复制
视图属于元数据（schema object），和表结构一样，应和代码一起版本化管理，通过自动化脚本在主从库统一执行。
- 禁止在生产环境主库上手工建视图后不管从库；所有 DDL 必须走发布流程，确保双端执行
- 在 CI/CD 流程中加入检查项：对比主从
information_schema.views的数量与定义哈希值 - 如果使用 ORM 或中间件生成视图，确保其初始化逻辑在从库启动时也运行一次
真正容易被忽略的是：视图缺失不会导致 Slave_SQL_Running = No，它安静地让业务查询失败。上线新视图后，务必手动验证从库是否存在且可查——别等监控告警才想起这事。
