单条update更新多行慢因逐行加锁、校验与日志写入，i/o和事务开销线性增长；高并发下锁等待雪球式放大；应分批控制在100–500行，避免大in列表或无条件limit。
UPDATE 单条语句更新多行为什么慢
因为数据库要对每行单独加锁、校验约束、写 binlog/redo log，即使 WHERE 条件走索引，I/O 和事务开销也随行数线性增长。尤其在高并发下，锁等待会雪球式放大。
- 避免用
UPDATE table SET col = ? WHERE id IN (1,2,3,...1000)一次性塞几千个 ID —— MySQL 会把它当一条语句执行，但内部仍逐行处理，锁住整个范围 - 若
id是主键且连续，BETWEEN比IN稍快；但若离散，IN实际会转成多个等值查找，优化器可能放弃索引 - PostgreSQL 对大
IN列表更敏感，容易触发顺序扫描；MySQL 8.0+ 对IN长度超过 1000 项会警告并降级执行计划
分批 UPDATE 的安全边界怎么定
不是越小越好，也不是越大越稳。核心是让单批事务控制在 100–500 行之间，同时确保不跨事务锁表或阻塞复制。
YXPHP企业网站管理系统4.0
下载
支持静态模板,支持动态模板标签,支持图片.SWF.FLV系列广告标签.支持百万级海量数据,绑定内置URL伪装策略(URL后缀名随你怎么写)，绑定内置系统升级策略(暂不开放升级),绑定内置模板付费升级策略(暂不开放更新)。支持标签容错处理,绑定内置攻击防御策略,绑定内置服务器优化策略(系统内存释放的干干净净)。支持离线运行,支持次目录,兼容U主机。支持会员功能,支持文章版块权限阅读,支持会员自主注册
- MySQL 下优先用
LIMIT+ 自增主键游标：先查出最小id，再UPDATE ... WHERE id BETWEEN ? AND ? LIMIT 500，比OFFSET更稳定 - 禁止用
UPDATE ... LIMIT 500无条件批量（如没WHERE）—— 它会随机选行，可能漏更或重复更 - PostgreSQL 必须显式加
ORDER BY再LIMIT，否则每次结果顺序不确定，导致同一批数据被反复处理 - 如果表有唯一约束或触发器，每批提交后检查影响行数是否为预期值，防止部分失败静默跳过
用 JOIN 替代子查询 UPDATE 的陷阱
MySQL 支持 UPDATE t1 JOIN t2 ON ... SET t1.col = t2.val，看似高效，但极易踩坑。
- 必须确保
t2中每个关联键只出现一次，否则 MySQL 会报错ERROR 1093 (HY000): You can't specify target table for update in FROM clause或产生非预期的重复更新 - JOIN 的驱动表要是小表（比如配置表），否则大表被全扫，性能反不如先查 ID 再
IN - 在 MySQL 5.7 中，
UPDATE ... JOIN不走t2的索引是常态；8.0 虽有改进，但仍建议EXPLAIN UPDATE（需用SELECT模拟）验证执行计划 - 不要在 JOIN UPDATE 中引用聚合函数（如
SUM()），MySQL 不支持，会直接报语法错误
WHERE 条件没走索引导致全表扫描怎么办
这是批量 UPDATE 最常见的性能断点：看着 SQL 很简单，实际执行时锁住整张表几秒甚至几分钟。
- 先用
EXPLAIN FORMAT=TRADITIONAL SELECT *模拟你的WHERE条件，确认type是ref或range，不是ALL或index - 常见诱因：对字段用函数（如
WHERE DATE(create_time) = '2024-01-01'）、隐式类型转换（WHERE user_id = '123'但user_id是INT）、字符集不一致（utf8mb4vsutf8） - 临时补救：加
FORCE INDEX（MySQL）或/*+ IndexScan(t1 idx_name) */（PostgreSQL），但只是掩耳盗铃，长期必须重构条件或补索引 - 如果业务允许，把模糊条件（如
LIKE '%abc%'）挪到应用层过滤，数据库只负责精确匹配和主键范围
