WHERE CURRENT OF 仅在PostgreSQL、SQL Server、DB2、Oracle等支持可更新游标的数据库中有效，MySQL和SQLite不支持；使用前须声明FOR UPDATE游标且未关闭，UPDATE必须紧随FETCH执行，推荐优先采用集合操作替代。
WHERE CURRENT OF 只在支持游标的数据库中有效
PostgreSQL、SQL Server（用 WHERE CURRENT OF 或 UPDATE ... FROM）、DB2 支持该语法；MySQL 和 SQLite 完全不支持，Oracle 用 WHERE CURRENT OF cursor_name 但要求游标必须是 FOR UPDATE 声明且未关闭。如果执行时报错 ERROR: syntax error at or near "WHERE" 或 ORA-01001: invalid cursor，先确认数据库类型和游标声明方式。
必须显式声明 FOR UPDATE 的可更新游标
游标默认只读，WHERE CURRENT OF 更新的前提是游标已用 FOR UPDATE 声明，并且未被 CLOSE。漏掉 FOR UPDATE 会导致更新静默失败或报错 cursor is not updatable。
- PostgreSQL 正确写法：
BEGIN; DECLARE my_cursor CURSOR FOR SELECT id, status FROM orders WHERE status = 'pending' FOR UPDATE; FETCH NEXT FROM my_cursor; UPDATE orders SET status = 'processing' WHERE CURRENT OF my_cursor; COMMIT;
- Oracle 注意：不能在 PL/SQL 匿名块外直接用
WHERE CURRENT OF，必须配合OPEN/FETCH/CLOSE流程，且游标变量需声明为REF CURSOR并FOR UPDATE - SQL Server 不支持标准
WHERE CURRENT OF，改用UPDATE ... FROM+ 游标变量或临时表关联
UPDATE 必须紧跟 FETCH，且不能跨事务提交
游标位置只在当前事务内有效，FETCH 后若未立即 UPDATE，后续再 FETCH NEXT 就会移动位置，导致 WHERE CURRENT OF 更新错行。更危险的是：如果在 FETCH 后执行了其他 DML（如另一条 UPDATE），可能触发锁等待或死锁。
- 正确顺序：
FETCH→UPDATE ... WHERE CURRENT OF→ （可选）再次FETCH - 禁止在
FETCH和UPDATE之间调用存储过程、插入日志表或执行网络请求 - PostgreSQL 中若事务未结束，其他会话对同一行的
UPDATE会被阻塞，直到本事务COMMIT或ROLLBACK
替代方案比硬套 WHERE CURRENT OF 更实用
真正需要“逐行处理+更新”的场景极少，多数可通过集合操作替代，既安全又高效。硬上游标容易忽略并发、性能和维护成本。
- 用子查询更新：
UPDATE orders SET status = 'processing' WHERE id IN ( SELECT id FROM orders WHERE status = 'pending' LIMIT 100 );
- 用 CTE + 窗口函数分批：
WITH batch AS (SELECT id FROM orders WHERE status = 'pending' ORDER BY id LIMIT 100) UPDATE orders SET status = 'processing' WHERE id IN (SELECT id FROM batch); - 业务逻辑复杂？把过滤条件和更新字段提取成临时表，再 JOIN 更新，避免游标状态管理
游标 + WHERE CURRENT OF 是个精确但脆弱的工具——它要求你完全掌控事务边界、锁行为和执行顺序。实际项目里，90% 的所谓“必须逐行更新”需求，拆开看只是没想清楚怎么用集合思维表达。
