如何借助SQL视图将多个旧系统的微服务数据库进行数据平滑整合

SQL Server跨库视图必须用四部分名称（Database.Schema.Object）显式指定，执行者需对每个跨库表单独授SELECT权限，UNION ALL各列类型须严格兼容且不可依赖隐式转换，视图内禁止ORDER BY，结果默认无序。

不能直接用视图跨库写入，也不能靠视图自动解决权限、类型或排序问题——它只是一层 SELECT 封装，整合必须分读/写两路设计。

SQL Server 跨库视图必须写全四部分名称

SQL Server 不会继承当前 USE 的数据库上下文，视图里所有跨库表都得显式写成 database.schema.object。漏写库名会报 Msg 1087 或 Msg 208。

• 错误写法：SELECT name FROM Users UNION ALL SELECT name FROM dbo.Users（前一个没指定库）
• 正确写法：SELECT name FROM db1.dbo.Users UNION ALL SELECT name FROM db2.dbo.Users
• schema 不一定是 dbo，如果是 sales 或 archive，必须写准，否则运行时报错
• 系统库也要写全，比如 master.sys.databases，不能简写为 sys.databases

UNION ALL 合并多源时字段类型必须手动对齐

SQL Server 按第一个 SELECT 子句的列类型决定最终结果列类型，后续子句对应列若类型不兼容，可能隐式转换失败或静默截断。

• 数值列建议统一转为 DECIMAL(12,2)，避免 INT 和 FLOAT 混用导致精度丢失
• 字符串列优先转 CAST(col AS VARCHAR(255))，别依赖隐式提升，PostgreSQL 和 SQL Server 对 TEXT/VARCHAR 兼容性处理不一致
• 空缺字段补 NULL 时必须显式声明类型，如 NULL AS status 不够，要写 CAST(NULL AS VARCHAR(20)) AS status
• 时间字段注意 DATE vs DATETIME2，类型不一致会导致 UNION 失败或索引失效

视图无法绕过权限检查，执行者需逐库授权

视图创建成功不代表能查。用户执行 SELECT * FROM v_user_union 时，SQL Server 会校验其对 db1.dbo.Users 和 db2.dbo.Users 是否都有 SELECT 权限。

• 典型报错：Msg 229, Level 14... The SELECT permission was denied on the object 'Users', database 'db2'
• 必须单独执行：GRANT SELECT ON db2.dbo.Users TO [user_name]（不能靠 db_owner 角色自动继承）
• 如果用了链接服务器（Linked Server），还要确认远程登录映射、RPC 和 RPC Out 已启用
• 权限变更后，视图缓存不会自动刷新，首次查询可能仍报错，需等计划清除或手动 DBCC FREEPROCCACHE

视图里不能加 ORDER BY，合并结果默认无序

SQL 标准规定视图定义中禁止 ORDER BY（除非配合 TOP 或 OFFSET/FETCH），否则创建失败。这意味着 UNION ALL 合并后的结果天然无序。

• 想保证顺序，必须在外层查询加 ORDER BY，例如：SELECT * FROM v_user_union ORDER BY id
• 不要指望视图里写 ORDER BY dt 能让下游查询自动有序——它会被忽略或报错
• 如果业务强依赖时序，且各源表 dt 字段类型/索引不一致，合并后排序性能可能骤降，建议先在各子查询里加 WHERE dt >= @cutoff 下推条件
• 测试时用 EXPLAIN 或执行计划看是否走了索引；没走就说明类型不一致或条件没下沉

最常被忽略的一点：视图只是语法层封装，不改变数据物理分布。跨库合并后，如果某库响应慢或网络抖动，整个视图查询就会卡住——它没有熔断、降级或超时机制，这些必须由应用层兜底。