游标慢的根本原因是单行迭代执行模型，而join是批量集合操作；应优先用update...from或merge替代游标逐行更新，函数调用需提前物化或改用内联表值函数。
游标慢的根本原因不是语法，是执行模型
数据库执行游标时，每 fetch 一行就触发一次引擎调度、一次锁检查、一次网络往返（即使本地），而 JOIN 是一次性做集合匹配，走索引合并或哈希连接，底层批量处理。只要数据能用关系代数表达，游标就大概率是错选。
- 常见错误现象：
DECLARE cur CURSOR FOR SELECT ...; OPEN cur; FETCH cur INTO ...; WHILE @@FETCH_STATUS = 0 BEGIN ... UPDATE ...; FETCH cur INTO ...; END这类结构在百万级表上可能跑几小时 - 典型使用场景：逐行更新状态字段（如
status = 'processed'）、根据某字段值调用函数生成新字段、跨表查补缺失关联信息 - 性能影响：游标默认是
READ_ONLY FORWARD_ONLY，但哪怕显式设成SCROLL，也改不了单行迭代本质；JOIN 则可利用INDEX SEEK或并行执行计划
把 UPDATE + 游标替换成 UPDATE ... FROM 或 MERGE
多数“逐行更新”其实只需要一次集合更新，关键在于把游标里的 WHERE id = @id 条件，改成主表与源数据的 JOIN 条件。
- 原游标写法问题：每次
UPDATE t SET col = ... WHERE id = @id都要走一次主键查找，N 行就是 N 次 B-Tree 查找 - 推荐写法：
UPDATE t SET t.status = s.new_status FROM orders t INNER JOIN #temp_updates s ON t.order_id = s.order_id—— 一次哈希连接搞定全部匹配 - 注意点：SQL Server 的
MERGE在并发更新时可能有死锁风险，UPDATE ... FROM更稳；MySQL 要用UPDATE t JOIN s ON ... SET t.col = s.val - 兼容性：PostgreSQL 不支持
UPDATE ... FROM语法，得用UPDATE t SET col = s.val FROM s WHERE t.id = s.t_id
游标里调函数？先看能不能内联或提前物化
如果游标里类似 SELECT dbo.calc_score(@user_id) 这种调用，90% 可以拆出来——函数结果要么能提前算好存临时表，要么能重写成 JOIN 子查询。
- 容易踩的坑：
SELECT ... FROM t WHERE dbo.expensive_fn(t.id) > 100会让函数对每行都执行；改成SELECT ... FROM t INNER JOIN #scores s ON t.id = s.id WHERE s.score > 100就只算一次 - 参数差异：标量函数（
RETURNS INT）无法自动内联，而内联表值函数（RETURNS TABLE AS RETURN (SELECT ...)）会被优化器展开，等价于子查询 - 实操建议：用
SET STATISTICS XML ON看执行计划，如果看到Compute Scalar下挂了函数调用节点，基本就是瓶颈所在
真需要逐行逻辑？用集合作为“控制流载体”
极少数情况（比如必须按时间顺序调用外部 API、依赖前一行计算结果），游标不可替代。但可以缩小它的作用域：只用游标做控制，把数据搬运和计算交给集合操作。
- 例如：处理流水账时需累加余额。不要在游标里
SET @balance = @balance + @amount，而是用窗口函数SUM(amount) OVER (ORDER BY ts ROWS UNBOUNDED PRECEDING)先算好所有余额，再用游标只负责发通知 - 为什么这样做：游标保留最简逻辑，避免在循环体内做 I/O、字符串拼接、条件分支等易出错操作
- 容易被忽略的地方：游标
DEALLOCATE必须显式写，否则会持续占用内存和锁资源；临时表命名别用#t这种模糊名，用#update_batch_202405便于排查残留
