视图执行报“找不到该视图”是因未连对库或 schema；SSMA 迁移后结果为空多因依赖对象改名；修改表结构后视图报“无效列名”需刷新元数据；CREATE 失败常因依赖顺序错误。
视图执行时报“找不到该视图”？先确认是否连对了库和 schema
这不是视图本身坏了，而是 SQL Server 根本没在你预期的地方找它。若依这类框架默认依赖 dbo schema，但如果你迁移时创建的数据库没显式指定所有者，或脚本里漏写了dbo. 前缀，查询就会失败——哪怕视图真在库里，也像藏在隔壁房间。
- 执行
SELECT SCHEMA_NAME(schema_id), name FROM sys.views，确认视图实际落在哪个 schema 下（常见是dbo，但也可能是ruoyi、test等） - 查当前连接上下文：
SELECT DB_NAME(), SCHEMA_NAME()，看是否连到了目标库，且默认 schema 是你期望的那个 - 临时修复：把原 SQL 里的
SELECT * FROM my_view改成SELECT * FROM dbo.my_view，快速验证是不是 schema 错位 - 长期方案：迁移前统一用
CREATE VIEW dbo.my_view AS ……显式声明所有者，避免靠默认值赌运气
SSMA 迁移后视图能查但结果为空？检查依赖对象是否被“悄悄改名”
SSMA 在转换 MySQL 视图到 SQL Server 时，会自动重写表名、字段别名甚至函数（比如 NOW()→GETDATE()），但不会帮你修底层表结构变更。如果源 MySQL 视图依赖一张叫sys_user 的表，而你在 SQL Server 里建成了 sys_users（多了 s），视图语法合法、能创建成功，但一查就空——因为底层FROM 指向的是个不存在的表名。
- 用
SELECT referenced_entity_name, referenced_schema_name FROM sys.sql_expression_dependencies WHERE referencing_entity_name = 'my_view'查真实依赖项 - 对比结果和目标库中实际存在的表 / 视图名，特别注意大小写、下划线、复数后缀等细微差异
- 不要直接 DROP 重建，先用
sp_helptext 'my_view'看原始定义，再手工调整FROM和JOIN部分 - MySQL 里不区分大小写的表名，在 SQL Server 默认实例中可能变成严格匹配，这也是隐形坑
修改基础表结构后视图报错“无效列名”？不是缓存问题，是元数据没刷新
SQL Server 不会自动感知底层表字段增删改，视图的元数据（列名、类型、可空性）是在创建时固化下来的。你给 sys_user 加了个 tenant_id 字段，但 vw_user_list 还是按老结构编译的，这时查它就会报错，哪怕 SELECT 里根本没用到tenant_id。
- 最稳妥做法：
ALTER VIEW dbo.vw_user_list AS SELECT ……重新执行一遍完整定义（不是只改底层表） - 偷懒但有效的方式：
EXEC sp_refreshview 'dbo.vw_user_list'，强制更新视图元数据缓存 - 注意：
sp_refreshview不解决逻辑错误（比如字段类型冲突），只同步结构；如果底层表删了某列，而视图还引用着，它会直接报错，必须人工干预 - 批量处理多个视图时，可用
SELECT 'EXEC sp_refreshview''' + name + ''';' FROM sys.views WHERE name LIKE 'vw_%'生成脚本
迁移后视图顺序错乱导致 CREATE 失败？别信 SSMA 自动生成的脚本顺序
视图 A 依赖视图 B，但 SSMA 导出的建库脚本里，A 排在 B 前面——这在 SQL Server 里直接报错。这不是 bug，是工具按字母序或创建时间排序的惯性，而 SQL Server 又不像 PostgreSQL 那样支持延迟解析，必须“先有 B，才能建 A”。
- 手动跑一遍依赖拓扑：
SELECT referencing_entity_name, referenced_entity_name FROM sys.sql_expression_dependencies WHERE referenced_class = 1 ORDER BY referencing_entity_name - 用 NineData 或
sp_depends（已弃用但还能用）辅助理清层级，把“被依赖的”（叶子节点）放前面，“依赖别人的”（根节点）放后面 - 简单粗暴法：先把所有
CREATE VIEW语句替换成ALTER VIEW，全部跑通后再统一替换回去——绕过创建顺序问题 - 真正要命的是循环依赖（A→B→A），这种情况 SQL Server 不允许，必须拆解逻辑，用 CTE 或临时表替代其中一环
视图迁移最麻烦的从来不是语法转换，而是那些看不见的绑定关系：schema 归属、依赖路径、元数据快照、创建顺序。每一步都得拿系统视图去对，不能凭感觉猜。
