游标跨库分表同步失败主因是“一边读一边写”和事务边界失控；须用本地临时表缓存数据、动态SQL拼表名并参数化传值、分批提交且配TRY...CATCH及游标/临时表清理。
直接用游标做跨库分表同步，90% 的失败都出在“一边读一边写”和“事务边界失控”上。游标本身不解决分布式一致性，它只是个逐行遍历工具；真正决定成败的是你怎么组织语句、控制锁、处理错误回滚。
为什么不能在游标循环里直接 INSERT INTO linked_server.db.schema.table？
SQL Server 对远程服务器的 INSERT 有硬性限制：如果目标是链接服务器（如 MJZFPT），且语句中含子查询、JOIN 或非确定性函数（如 GETDATE()），会报错 Msg 7391, Level 16：“无法执行该操作，因为该操作将多个数据库置于一个事务中”。
- 游标 FETCH 后立刻对链接库执行 INSERT，本质就是跨库事务，触发该错误
- 即使加了
SET XACT_ABORT ON，也无法绕过 SQL Server 的两阶段提交限制 - 正确做法是把数据先拉到本地临时表（
#sync_buffer），再用本地INSERT ... SELECT推过去
游标 + 分表路由：如何根据分片键动态拼目标表名？
不能用 @target_table = 't_user_' + CAST(@shard_id AS VARCHAR) 然后直接 INSERT INTO @target_table —— T-SQL 不允许变量作对象名。必须走动态 SQL，且必须用 QUOTENAME() 防注入和特殊字符。
- 分表逻辑要提前固化：比如
@shard_id = ABS(CHECKSUM(@user_id)) % 4，算出后映射为't_user_0'～'t_user_3' - 拼接时用
N'INSERT INTO ' + QUOTENAME(@target_db) + N'.' + QUOTENAME(@target_schema) + N'.' + QUOTENAME(@target_table) - 严禁拼接用户输入字段值，所有值必须通过
sp_executesql的参数化传入
游标同步必须配临时表 + 批量提交，否则性能崩盘
单行游标 + 单行远程 INSERT，吞吐量通常低于 50 行/秒；而大表同步动辄百万级，光网络往返就拖死。真实场景下，必须把游标结果集缓存到本地临时表，再按 1000～5000 行一批批量推。
- 定义
#batch_cursor临时表，结构与源表一致，加IDENTITY(1,1) AS rownum方便分页 - 游标只用于从源表查 ID 列（如
SELECT id FROM source_table WHERE status = 'pending'），把 ID 插入#batch_cursor - 外层用
WHILE @@ROWCOUNT > 0循环：每次取TOP 2000ID，JOIN 原表取全量数据，INSERT 到目标分表 - 每批后显式
COMMIT，避免长事务锁住源表
最容易被忽略的坑：游标未关闭 + 临时表残留 + 错误未捕获
存储过程退出前没 CLOSE 和 DEALLOCATE 游标，下次执行会报 Msg 16915：“游标已存在”；临时表没加 DROP TABLE #xxx，可能因会话复用导致结构冲突；更致命的是没包 TRY...CATCH，一报错就中断，后续批次全丢。
- 所有游标声明后，必须配对
CLOSE @cur_name; DEALLOCATE @cur_name; - 临时表命名加时间戳或会话ID，如
#sync_batch_+CONVERT(VARCHAR(12), @@SPID) -
CATCH块里至少记录ERROR_MESSAGE()到日志表，并THROW重新抛出，不能静默吞掉
