跨实例INSERT超时本质是远程查询超时，由remote query timeout配置控制，默认600秒；需用sp_configure调整，而非修改连接字符串超时设置。
跨实例 INSERT 时连接超时，本质是远程查询超时，不是连接池问题
遇到 INSERT INTO remote_db.schema.table SELECT ... FROM local_table 类语句报超时，错误里带 System.Data.SqlClient.SqlException (0x80131904): 超时已过期，基本可以排除本地连接字符串的 Connect Timeout 设置——那只是控制“建立 TCP 连接”的时间。真正卡住的是 SQL Server 执行远程查询（比如通过链接服务器）时的命令执行时限，默认仅 30 秒。
- 链接服务器（Linked Server）发起的跨实例查询走的是
sp_executesql或分布式查询路径，受remote query timeout服务器配置项约束，而非连接字符串里的CommandTimeout - 如果你用的是
OPENQUERY或四部分名（[server].[db].[schema].[table]），超时由目标实例的remote query timeout决定，本地客户端设置无效 - 错误堆栈中若出现
[Post-Login] complete=14025这类耗时分布，说明连接已建好，但查询阶段卡在远程端，这时调大本地Connection Timeout没用
检查并修改 remote query timeout 配置
这个值默认是 600 秒（10 分钟），但很多生产环境被人为调低，或因链接服务器配置未继承主实例设置而回退为 0（即无限等待，但实际受底层网络或驱动限制，反而更易出错）。
- 查当前值：
EXEC sp_configure 'remote query timeout' - 设为 0（不限制）或合理值（如 1800）：
EXEC sp_configure 'remote query timeout', 1800; RECONFIGURE; - 注意：需
sysadmin权限；修改后立即生效，无需重启服务 - 如果链接服务器指向的是非 SQL Server（如 Oracle、MySQL），该配置不生效，需改用
EXEC sp_serveroption设置其query timeout
避免用四部分名直接 INSERT，改用分步 + 批量提交
即使调高了超时，跨实例大 INSERT 仍不稳定：网络抖动、远程锁争用、日志增长都会导致中途失败，且无法回滚整个语句。
- 不要写：
INSERT INTO [remote_srv].[db].[dbo].[t] SELECT * FROM local_t - 改用：先
SELECT TOP N拉数据到本地临时表，再用SqlBulkCopy或分批次INSERT推过去 - 对远程目标启用
TRUSTWORTHY ON或签名存储过程可绕过部分安全检查，但风险高，不推荐 - 若必须用链接服务器，确保远程实例已开启
RPC Out：EXEC sp_serveroption 'remote_srv', 'rpc out', true
链接服务器底层协议和防火墙常被忽略
超时前若出现 pre-login handshake=14979，说明卡在预登录握手阶段，跟查询无关，而是网络或认证层问题。
- 确认链接服务器使用的登录账号在远程实例上有对应映射，且未被策略（如密码过期、登录被禁）拦截
- 检查远程 SQL Server 是否监听 TCP 1433（或自定义端口），Windows 防火墙是否放行该端口入站规则
- 用
telnet remote_ip 1433测试端口连通性；若不通，Connect Timeout设置再大也白搭 - 避免混用命名管道（Named Pipes）和 TCP/IP：链接服务器属性里明确指定使用
TCP/IP协议，并在远程 SQL Server 配置管理器中禁用命名管道
真正麻烦的不是超时数字本身，而是跨实例操作天然缺乏事务一致性保障。哪怕把所有 timeout 都设成 0，只要中间网络断一下、远程日志满一下、或者对方做了索引重建，你的 INSERT 就可能卡死或静默失败。所以优先考虑把数据导出为文件再导入，比硬扛链接服务器更可控。
