不能直接用UPDATE加WHERE预览结果，因为UPDATE本身不返回被修改的行（除非数据库支持RETURNING），必须先用相同WHERE条件执行SELECT *验证影响范围，确保逻辑一致，避免漏括号、优先级错误或函数遗漏；PostgreSQL可用RETURNING返回新值，但需CTE或FROM自连接获取旧值；MySQL/SQL Server只能分步SELECT+UPDATE并依赖事务保证一致性。
为什么不能直接用 UPDATE 语句加 WHERE 预览结果？
因为 UPDATE 不返回被修改的行（除非数据库支持 RETURNING），你执行完才知道改了什么，没法提前确认。最稳妥的方式是把 UPDATE 的 WHERE 条件原样挪到 SELECT 里查一遍——但要注意：条件逻辑必须完全一致，否则预览和实际影响范围对不上。
常见错误是复制时漏掉括号、混淆 AND/OR 优先级，或误用了函数（比如在 UPDATE 里用 UPPER(name)，但在 SELECT 里忘了加）。建议直接从 UPDATE 语句中提取 WHERE 子句，粘贴后只改开头为 SELECT *。
PostgreSQL 怎么用 RETURNING 一次性看到修改前后的值？
PostgreSQL 支持 RETURNING，能在执行 UPDATE 同时返回被修改的行，比先 SELECT 再 UPDATE 更可靠（避免并发修改导致预览与实际不一致）。
-
UPDATE users SET status = 'active' WHERE id IN (1,2,3) RETURNING id, name, status;—— 返回修改后的字段值 - 想看修改前的值？得配合
OLD.*或子查询，但 PostgreSQL 不支持直接RETURNING OLD.*；可行做法是先SELECT记录原始状态，再UPDATE，或用 CTE：
WITH old_data AS ( SELECT id, name, status FROM users WHERE id IN (1,2,3) ) UPDATE users SET status = 'active' WHERE id IN (SELECT id FROM old_data) RETURNING (SELECT json_agg(old_data.*) FROM old_data);
RETURNING 只在当前事务内生效，且无法跳过实际写入——它不是“预览”，而是“带反馈的执行”MySQL 和 SQL Server 没有 RETURNING，怎么安全预览？
这两者必须分两步：先 SELECT，再 UPDATE，中间靠事务隔离保证一致性。
- 开启事务：
BEGIN TRANSACTION（SQL Server）或START TRANSACTION（MySQL） - 执行预览查询：
SELECT id, name, email FROM users WHERE created_at - 确认无误后执行：
UPDATE users SET status = 'archived' WHERE created_at - 检查影响行数：
SELECT ROW_COUNT();（MySQL）或SELECT @@ROWCOUNT;（SQL Server） - 最后
COMMIT或ROLLBACK—— 别忘了这一步，否则锁一直挂着
容易踩的坑：没开事务就直接 SELECT，结果别人在你预览完、执行前改了数据，导致误更新；或者忘了关事务，锁表。
WHERE 条件里含子查询或函数时，预览要特别小心
比如 UPDATE orders SET processed = true WHERE id IN (SELECT order_id FROM logs WHERE event = 'paid')。这种不能简单复制 WHERE 到 SELECT，因为子查询可能返回空、重复或受权限限制。
- 先单独跑子查询：
SELECT order_id FROM logs WHERE event = 'paid';，确认结果合理 - 再用这个结果做预览：
SELECT * FROM orders WHERE id IN (101, 102, 105);（把子查询结果硬编码进去） - 如果子查询太慢或不稳定，考虑加
LIMIT测试前几条：SELECT * FROM orders WHERE id IN (SELECT order_id FROM logs WHERE event = 'paid' LIMIT 10); - 涉及时间函数如
NOW()、CURRENT_DATE的，预览和执行之间哪怕差 1 秒，结果都可能不同——这种场景更适合用具体时间字面量测试
真正麻烦的是嵌套多层、带窗口函数或依赖会话变量的条件，这时候预览只能逼近，没法 100% 精确。别省那几秒，手动生成测试数据集验证逻辑更靠谱。
