利用SQL视图平滑整合多个旧系统微服务数据库数据

先说一个核心判断：跨库视图，听上去很美，但用起来坑不少。如果你指望靠它一键打通多个库，那大概率会碰一鼻子灰。SQL Server 的视图本质是一层 SELECT 封装，它不会帮你解决权限、类型或排序问题，更不会替你分担网络抖动。能做的，就是把多个库的表老老实实的“拼在一起”给你看。

所以，用跨库视图，你得提前想好：读归读，写归写，别指望它能替你自动搞定一切。

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

SQL Server 的视图可不会继承当前数据库上下文。视图里但凡涉及跨库表，必须写成 数据库名.架构名.对象名 这种四部分格式。漏了库名，等着你的就是 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 的列类型当模板，后续 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 和 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 角色自动继承，它没那么智能。
• 如果用了链接服务器，还得确认远程登录映射、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 下推条件，缩小数据范围。
• 测试时一定要看执行计划，看看索引有没有走。没走？说明类型不统一或条件没下沉，得想办法调。

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