MySQL视图失效源于执行时校验而非创建时，需分步重建：先测试验证、重写GROUP BY、展开SELECT *、显式CAST JSON字段、统一collation。
视图失效不是“没编译”，是执行时才暴露问题
MySQL 的视图定义只是文本快照，CREATE VIEW 本身不校验字段是否存在、类型是否兼容、collation 是否混用。升级到 8.0 后，SELECT * 列序可能变、字符集默认排序规则从 utf8mb4_general_ci 变成 utf8mb4_0900_as_cs、SQL mode 新增 ONLY_FULL_GROUP_BY，这些都不会让建视图失败，但第一次 SELECT 就崩。所以“刷新”不是重跑一遍 CREATE OR REPLACE VIEW 就完事——它大概率成功，但依然失效。
不能批量执行 CREATE OR REPLACE VIEW
盲目遍历 INFORMATION_SCHEMA.VIEWS 并执行 CREATE OR REPLACE VIEW 会触发连锁错误：
- 引用已删除字段（如
dept_name）的视图，重建后仍能创建成功，但后续查询直接报Unknown column 'dept_name' in 'field list' - 含
SELECT *的视图，重建后列顺序可能因表结构隐式变化而错位，下游 JDBC 按索引取值（如rs.getString(2)）直接取错字段 - 字符集 collation 不一致（如老表用
utf8mb4_general_ci，新库默认utf8mb4_0900_as_cs）会导致Illegal mix of collations，且只在执行时报错 - SQL mode 改变后，原
GROUP BY id+SELECT name类语句直接失败，但视图定义本身合法，CREATE OR REPLACE不拦截
安全定位+分步重建的实操路径
先验证再重建，避免锁表和误操作：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用系统表生成测试语句：运行
SELECT CONCAT('SELECT * FROM ', TABLE_SCHEMA,'.', TABLE_NAME,' LIMIT 1;') AS test_sql FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys');，把结果复制到客户端逐条执行，记录哪些崩、报什么错 - 查 SQL mode 影响：执行
SELECT @@sql_mode;，若含ONLY_FULL_GROUP_BY，所有含GROUP BY的视图都必须重写，确保非聚合字段全部出现在GROUP BY中 - 展开
SELECT *：对每个失效视图，用DESCRIBE table_name;确认当前字段顺序，手工替换视图定义中的*为显式字段列表 - JSON 字段加
CAST：若视图含JSON_EXTRACT(json_col, '$.key')，必须改为CAST(JSON_EXTRACT(json_col, '$.key') AS CHAR)，否则 8.0 默认返回 JSON 类型，与其他字符串字段拼接时报错
重建后必须验证的三个硬性点
跳过任一环节，视图看起来“重建成功”，实际仍不可用：
-
SELECT *必须展开为显式字段列表——哪怕表结构没变，也要确认顺序，防止 ORM 或旧代码按列序取值错乱 - 所有 JSON 字段操作必须显式
CAST成目标类型（CHAR、UNSIGNED等），不能依赖隐式转换 - 字符集 collation 必须统一：建视图前先确认基表 collation，必要时在视图字段上加
COLLATE utf8mb4_unicode_ci显式指定
最易被忽略的是 collation 混用——它不会在 CREATE VIEW 时报错，但只要两个字段 collation 不同又参与比较或连接，SELECT 就立即失败，且错误信息极不直观。
