生产执行UPDATE/DELETE前必须先用BEGIN TRANSACTION包裹并注释COMMIT，执行后校验影响行数，异常则立即ROLLBACK；WHERE须带索引字段、禁用函数包裹、避免裸条件；大更新需分批，严禁依赖测试环境验证。
先用 BEGIN TRANSACTION 包住再执行
所有 UPDATE / DELETE 脚本进生产前，第一件事不是点执行，而是手动加事务头尾。哪怕只有一条语句，也必须写成：
BEGIN TRANSACTION; UPDATE users SET status = 2 WHERE id IN (1001, 1002, 1003); -- COMMIT;
注意：COMMIT 行要注释掉，先运行。这样执行后不会真正提交，只进事务暂存状态。
- 查
@@ROWCOUNT（SQL Server）或ROW_COUNT()（MySQL）确认影响行数是否符合预期 - 如果行数异常（比如该改 3 行却显示 3000 行），立刻
ROLLBACK，不用犹豫 - 确认无误后再取消注释
COMMIT并执行——这一步必须人工二次确认
WHERE 条件必须带索引字段且禁止裸条件
不带 WHERE 的 UPDATE 或 DELETE 在生产库属于“红色操作”，一律禁止。但带了 WHERE 也不等于安全，常见翻车点：
-
WHERE created_at > '2025-01-01'—— 如果created_at没索引，可能锁全表甚至超时 -
WHERE name = '张三'—— 名字重复率高，易误伤，应补上唯一标识如AND tenant_id = 123 - 避免使用函数包裹字段：
WHERE DATE(created_at) = '2025-09-01'会跳过索引，改用范围查询
上线前用 EXPLAIN（MySQL/PostgreSQL）或 SET STATISTICS IO ON（SQL Server）看执行计划，确认走了索引扫描而非全表扫描。
分批执行大更新，别一次性干完
影响行数预估超过 5000 行的 UPDATE / DELETE，必须拆成小批次，否则容易：锁表时间长、主从延迟飙升、触发监控告警、OOM。
- MySQL 推荐用
LIMIT+ 循环（应用层控制）：UPDATE orders SET status = 3 WHERE status = 2 ORDER BY id LIMIT 1000 - PostgreSQL 可用
WHERE ctid IN (SELECT ctid FROM ... LIMIT 1000)避免重复扫描 - SQL Server 用
TOP (1000)+WHERE id > @last_id游标式推进 - 每次执行后
SELECT COUNT(*)校验已处理量，并记录到日志表（含时间戳、批次号、影响行数）
别信“测试环境跑过就没问题”
测试库数据量、分布、索引、统计信息都和生产不同，脚本在测试库秒级完成，在生产可能卡死。真实风险常藏在这些地方：
- 生产有分区表，但脚本没指定分区键，导致跨分区扫描
- 测试库关闭了外键检查，生产开启后 UPDATE 触发级联更新，放大影响
- search_path 设置不同（PostgreSQL），
UPDATE users实际执行的是 public.users 还是 auth.users？ - 字符集差异导致 WHERE 条件隐式转换，索引失效（如 utf8mb4 vs latin1）
最稳妥的做法：把脚本在影子库（与生产同规格、同步延迟
