linked server是sql server用于跨服务器（不同实例）数据访问的机制，非同实例跨库无需使用；它通过ole db驱动实现远程实例本地化访问，适用于跨服务器join、异构数据库查询等场景。
SQL Server 跨数据库表关联，必须用 Linked Server；跨实例（不同服务器）才需要它，同实例跨库直接用 数据库名.架构名.表名 就行，别绕弯。
Linked Server 是什么，什么时候非用不可
Linked Server 不是“跨库”，而是“跨服务器”——即两个独立运行的 SQL Server 实例（哪怕在同一台物理机上，只要实例名不同，就属于跨服务器）。它本质是让本地 SQL Server 通过 OLE DB 驱动，把远程实例当成本地对象来访问。
常见误判场景：
- 以为同一台机器上的
SQL2019和SQL2022实例能直接JOIN—— 不行，必须建 Linked Server - 把同实例下
DB_A.dbo.T1和DB_B.dbo.T2当成跨服务器 —— 这根本不需要 Linked Server，四段式写法也只适用于跨服务器 - 在 Azure SQL 托管实例中尝试创建 Linked Server —— 不支持，得换方案（如数据复制或应用层聚合）
配置 Linked Server 的三个关键实操点
图形界面（SSMS）操作快，但容易漏掉权限和连接验证。建议按顺序确认以下三点：
-
数据源字段必须写对：不是只填 IP 或主机名。如果目标实例监听非默认端口（比如 1434），必须写成
192.168.1.100,1434；如果是命名实例，要写ServerName\InstanceName，不能只写ServerName -
安全性选项卡别选“不进行身份验证”：这会走匿名映射，远程端通常拒绝。应勾选“使用此安全上下文”，填一个远程有效的 SQL 登录账号（严禁用
sa），且该账号在目标库中至少有db_datareader角色 -
建完立刻测试连通性：执行
SELECT TOP 1 * FROM [LinkedServerName].[master].[sys].[databases]。若报错Cannot initialize the data source object，大概率是提供程序没装（如缺失SQL Server Native Client）或防火墙拦截了 1433 端口
跨服务器 JOIN 的两种写法及性能差异
写法本身简单，但执行计划和资源消耗天差地别：
-
四段式直接查询：
SELECT a.id, b.name FROM local_db.dbo.t1 a JOIN [RemoteSrv].[remote_db].[dbo].[t2] b ON a.id = b.id。SQL Server 会把整个t2表拉到本地再JOIN，远程表无索引、大数据量时极慢 -
用
OPENQUERY：SELECT a.id, b.name FROM local_db.dbo.t1 a JOIN OPENQUERY([RemoteSrv], 'SELECT id, name FROM remote_db.dbo.t2') b ON a.id = b.id。这时查询在远程执行，只传结果集回来，性能好得多——但要求远程 SQL 必须能独立解析该语句（不能含本地变量、临时表） - 注意：
OPENQUERY中的 SQL 字符串里不能直接拼接参数，要用动态 SQL 或存储过程封装
为什么你查不到远程表的智能提示或元数据
SSMS 对 Linked Server 的元数据支持很弱。即使配置成功，[RemoteSrv].[remote_db].[dbo].[t2] 在对象资源管理器里可能不展开，SELECT * 时也不会自动补全字段名。
这不是配置失败，是设计限制。解决办法只有两个：
- 先在远程服务器上执行
sp_help 't2'查清字段结构，手动写全列名 - 用
SELECT * FROM OPENQUERY([RemoteSrv], 'SELECT * FROM remote_db.dbo.t2 WHERE 1=0')获取空结果集，看列定义（SSMS 会显示字段名）
另外，Linked Server 上的表无法参与本地统计信息更新，执行计划容易失真，复杂查询务必加 OPTION (RECOMPILE) 强制重编译。
