核心解法是将百万级update分批为小事务，确保where走索引、用主键范围分片、每批独立提交并控制节奏。否则必然导致锁表、iops暴增或磁盘打满。
直接执行百万级 UPDATE 几乎必然导致服务卡顿或中断——不是“会不会”，而是“卡多久、影响多广”的问题。核心解法只有一个：把大更新切成可控小事务，同时确保每批都能快速定位、稳定执行、不抢锁。
WHERE 条件必须走索引，否则等于主动锁表
这是最常被跳过的致命检查。MySQL 在 WHERE copyright != 6 这类条件上若 copyright 无索引，就会全表扫描；InnoDB 行锁可能升级为表锁（尤其在 REPEATABLE READ 隔离级别下），其他查询全部排队。PostgreSQL 虽保持行锁，但全表扫描会吃光 shared_buffers，WAL 写入暴增。
- 用
EXPLAIN UPDATE ...（MySQL）或EXPLAIN (ANALYZE) UPDATE ...（PostgreSQL）验证key列是否非NULL - 避免函数操作：
WHERE DATE(created_at) = '2024-01-01'→ 改成WHERE created_at >= '2024-01-01' AND created_at - 复合索引注意最左前缀：要查
status = 'pending' AND created_at > '2023-01-01'，索引必须是(status, created_at)，而非仅created_at
分批必须用主键/有序字段 + 稳定范围，别信 LIMIT
LIMIT 在 PostgreSQL 中根本不能直接用于 UPDATE；在 MySQL 中虽支持，但若期间有新数据插入或删除，WHERE id > ? LIMIT 1000 会漏行或重复更新——因为 OFFSET 类逻辑本质不可靠。
- 安全做法：用主键范围，例如
WHERE id BETWEEN 10001 AND 15000 AND status = 0，每次递增固定步长 - PostgreSQL 必须用子查询兜底：
UPDATE t SET x = 1 WHERE id IN (SELECT id FROM t WHERE status = 0 ORDER BY id LIMIT 1000) -
ORDER BY字段必须有索引，否则LIMIT失效且触发全表扫描 - 每批大小建议 500–5000 行，取决于单行体积和
innodb_log_file_size（MySQL）或wal_writer_delay（PG）容量
每批独立事务 + 显式控制节奏，别包进一个大事务
把 100 万行塞进一个事务，等于要求数据库全程持有所有行锁、写满 undo log、阻塞所有并发写入。更危险的是：长事务会阻止 VACUUM（PG）或 purge（MySQL），undo 日志持续膨胀，最终磁盘打满。
- 每批执行前
BEGIN，成功后立刻COMMIT；失败则ROLLBACK并重试 - 批次间加
SLEEP(0.1)（PG）或DO SLEEP(0.5)（MySQL 存储过程），缓解 IOPS 突刺 - 应用层必须检查
ROW_COUNT()（MySQL）或GET DIAGNOSTICS row_count = ROW_COUNT（PG），返回 0 才终止循环 - 严禁在存储过程中裸写循环更新——MySQL 多线程调用时若访问顺序不一致（如未
ORDER BY id），极易触发死锁错误1205
复杂场景优先用临时表 + JOIN，而不是硬拼 WHERE
当更新值依赖计算、关联其他表、或来自外部文件（如 CSV 导入），硬写 WHERE 条件不仅难调试，还容易因条件膨胀导致执行计划失效。
- 先建临时表：
CREATE TEMPORARY TABLE tmp_update (id INT PRIMARY KEY, new_value VARCHAR(32)) - 批量写入：
INSERT INTO tmp_update VALUES (1,'a'),(2,'b'),...;（每批 ≤ 1000 行防max_allowed_packet溢出） - 对
tmp_update.id加索引（即使临时表也要加） - 再执行：
UPDATE users u JOIN tmp_update t ON u.id = t.id SET u.status = t.new_value - 避免在
SET中调用NOW()等非确定性函数，否则优化器可能放弃使用索引
真正难的不是写出能跑的 SQL，而是在高负载生产环境里让每一行更新都可预期、可中断、可回溯。索引有效性、事务边界、批次稳定性，三者缺一不可——少验一个，就可能半夜被报警叫醒。
