MySQL视图报错“Unknown column”或“Table doesn't exist”主因是底层表结构变更（字段删/改名、表DROP/重命名），因视图仅存储SQL文本、不校验实时依赖；需通过information_schema.VIEWS或SHOW CREATE VIEW定位问题字段，手动验证并重建视图。
视图查询报错“Unknown column”或“Table doesn't exist”
这不是视图语法错了，而是它引用的底层对象已经变了——字段被删、重命名，或者表本身被 DROP 或改名。MySQL 视图不校验依赖实时性，只存 SQL 文本，所以创建成功 ≠ 能查。
- 先确认错误是否真由结构变更引起：执行
SELECT * FROM information_schema.VIEWS WHERE TABLE_NAME = 'your_view_name';，看VIEW_DEFINITION里写的字段和表名，再对比当前库中实际存在的表结构 - 用
SHOW CREATE VIEW `your_view_name`;拿到原始定义，手动在客户端执行该 SELECT 语句，观察具体哪一行报错（比如SELECT user_id, dept_name FROM sys_user中dept_name已被改为department_name） - 别信
*：如果视图里用了SELECT *，哪怕只是加了个字段，返回列顺序和数量就变了，JDBC 按索引取值（rs.getString(2)）会直接读错；ORM 缓存元数据更难察觉
MySQL 8.0 迁移后视图空结果或字段错乱
常见于低版本（如 5.7）迁到 8.0，尤其涉及 GROUP BY、JSON 函数或隐式类型转换时。不是数据丢了，是 SQL mode 变了，导致查询被静默截断或拒绝执行。
- 执行
SELECT @@sql_mode;，重点看是否含ONLY_FULL_GROUP_BY。旧视图若写SELECT id, name FROM t GROUP BY id，新环境会报错或返回非预期结果 - 检查 JSON 函数行为变化：
JSON_EXTRACT(json_col, '$.field')在 8.0+ 默认返回标量而非字符串，WHERE JSON_EXTRACT(...) = 'val'可能失效，需显式转类型：CAST(JSON_EXTRACT(...) AS CHAR) - 运行
SELECT referenced_table_name, referenced_column_name FROM information_schema.KEY_COLUMN_USAGE WHERE table_name = 'your_view_name' AND table_schema = 'your_db';不可靠——它只反映外键关系，不反映视图真实依赖。真要查依赖，得用SELECT * FROM mysql.proc WHERE db = 'your_db' AND name = 'your_view_name';（MySQL 5.7）或解析VIEW_DEFINITION字段
ALTER TABLE 后视图仍报“无效列名”，不是缓存问题
SQL Server 有 sp_refreshview，但 MySQL 没这机制。视图元数据在创建时固化，改表结构不会自动更新视图逻辑。
- 必须重建视图：用
CREATE OR REPLACE VIEW your_view AS ...，且完整重写整个 SELECT 语句——不能只改表结构就指望视图自动适配 - 注意 MySQL 版本限制：5.7 及以前不支持
CREATE OR REPLACE VIEW，必须先DROP VIEW再CREATE VIEW，而 DROP 会中断依赖它的应用或其它视图 - 嵌套视图要小心顺序：如果
vw_a依赖vw_b，而vw_b又依赖t_user，那得先修t_user，再重建vw_b，最后重建vw_a，否则中间层会因依赖缺失而创建失败
DEFINER 权限不足导致视图无法访问
视图执行时，默认以 DEFINER 用户身份检查底层表权限。迁移后即使该用户存在，也可能没被授予新库/表的 SELECT 权限。
- 查定义：
SHOW CREATE VIEW `your_view`;看开头类似DEFINER=`admin`@`%`的行 - 确认用户存在：
SELECT User, Host FROM mysql.user WHERE User = 'admin'; - 补权限：
GRANT SELECT ON your_db.t_user TO 'admin'@'%'; FLUSH PRIVILEGES;。别漏FLUSH PRIVILEGES，否则权限不生效 - 不想维护 DEFINER？建视图时用
SQL SECURITY INVOKER，让视图以调用者权限运行，但要求每个调用者都得有底层表权限——适合权限模型清晰的场景
视图不是活的代理，它不感知底层变化。每次改表结构，都要主动验证所依赖的视图能否查、查得对；靠 CREATE OR REPLACE 偷懒，往往只是把错误从运行时报，推迟到下次查询时才暴露。
