不能批量执行create or replace view——因视图定义不校验字段存在性、类型兼容性及collation一致性，select *列序变化、字符集混用、sql mode变更等均导致运行时错误而非定义时失败。
直接批量修复不现实——MySQL 不提供“一键重编译所有视图/存储过程”的机制，必须按依赖关系逐个验证、改写、重建。盲目用脚本遍历 INFORMATION_SCHEMA.VIEWS 或 ROUTINES 并执行 CREATE OR REPLACE，大概率触发连锁报错甚至锁表。
为什么不能用脚本批量跑 CREATE OR REPLACE VIEW？
视图定义只是 SQL 文本快照，不校验字段是否存在、类型是否兼容、collation 是否混用。批量执行时：
- 旧视图若含
SELECT *，重建后列序可能变化，下游 JDBC 按索引取值（如rs.getString(2)）直接错位 - 引用了已删字段（如
dept_name）的视图，CREATE OR REPLACE会成功，但首次SELECT就报Unknown column - 字符集 collation 不一致（如老表用
utf8mb4_general_ci，新默认是utf8mb4_0900_ai_ci）会导致Illegal mix of collations，且错误只在执行时暴露 - SQL mode 改变（如启用了
ONLY_FULL_GROUP_BY）会让原GROUP BY id+SELECT name的语句直接失败，但定义本身合法
如何安全批量定位失效视图和存储过程？
先不动代码，用系统表+执行验证组合扫描真实问题点：
- 查所有视图定义并手动执行其
SELECT语句：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');把结果复制到客户端逐条运行，看哪条崩 - 查所有存储过程，重点盯
ROUTINE_DEFINITION中是否含 MySQL 8.0 新保留字：SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_DEFINITION REGEXP '(rank|json|group|order|partition|window)\b' AND ROUTINE_TYPE = 'PROCEDURE';
匹配到的必须加反引号，如`rank` - 查当前 SQL mode：
SELECT @@sql_mode;若含ONLY_FULL_GROUP_BY，所有 GROUP BY 视图都得重写 SELECT 列表，确保非聚合字段都在 GROUP BY 中
重建时必须处理的三个硬性兼容点
跳过任一环节，重建完照样失效：
-
SELECT *必须展开为显式字段列表——哪怕表结构没变，也要用DESCRIBE table_name;确认顺序，避免 ORM 按列序取值错乱 - JSON 字段操作必须显式
CAST：JSON_EXTRACT(json_col, '$.name')→CAST(JSON_EXTRACT(json_col, '$.name') AS CHAR)，否则 8.0 默认返回JSON类型，字符串比较会失败 - 所有字段名、变量名若撞上保留字（
rank、json、group、order等），必须全局加反引号，包括DECLARE、SELECT、UPDATE SET、INSERT INTO (...) VALUES所有位置
最容易被忽略的执行时机问题
视图和存储过程不是定义完就生效的——它们的解析发生在**首次执行时**。这意味着：
- 你改完一个视图，
SELECT第一次会卡住几秒（服务端做元数据校验），之后才返回结果或报错 - 应用连接池里可能缓存了旧执行计划，即使重建了视图，老连接仍可能走旧路径，需重启应用或清空连接池
- 存储过程中若调用其他已失效的视图，错误不会在
CREATE PROCEDURE阶段暴露，而是在调用时才抛出，必须实际跑一遍业务逻辑路径
