大更新触发OOM而非变慢，是因为数据库或客户端将整批结果集、事务日志、排序/连接缓冲全加载进内存，如MySQL的sort_buffer_size、PostgreSQL的work_mem及JDBC默认fetchSize=-1导致堆内存飙升。为什么大更新会 OOM，而不是慢？SQL 大批量 UPDATE 触发内存溢出（OOM），往往不是因为语句写错了，而是数据库或客户端默认把整批结果集、事务日志、临时排序/连接缓冲全加载进内存。比如 MySQL 的 sort_buffer_size、PostgreSQL 的 work_mem，甚至 JDBC 驱动默认启用的 fetchSize 为 -1（即拉取全部），都会让应用端堆内存瞬间飙高。常见错误现象：java.lang.OutOfMemoryError: Java heap space 出现在执行完 executeUpdate() 后、但还没 commit 前；或者 PostgreSQL 报 ERROR: out of memory 在 UPDATE ... FROM 场景里。别依赖“单条 SQL 更快”——它可能更快地压垮内存确认你的驱动是否自动缓存结果：MySQL Connector/J 默认 useCursorFetch=true 才能流式读，否则 ResultSet 会预加载全部UPDATE 本身不返回结果集，但如果你用 SELECT ... FOR UPDATE + 循环更新，就极易触发客户端 OOMMySQL 分段 UPDATE 怎么写才不锁表太久直接 WHERE id BETWEEN ? AND ? 是最稳妥的分段方式，前提是 id 是主键或有高效索引。避免用 LIMIT + OFFSET，因为偏移越大，扫描行数越多，性能断崖式下跌。示例（安全可控）：UPDATE orders SET status = 'shipped' WHERE id >= 10000 AND id < 20000 AND status = 'pending';每次更新控制在 1k–5k 行以内，具体看单行数据大小和索引效率务必在 WHERE 条件里复用已有索引字段，不要写成 WHERE status = 'pending' LIMIT 1000 —— 这会强制全表扫描加 AND status = 'pending' 这类过滤条件，防止重复更新已处理的行注意 MySQL 5.7+ 的 innodb_lock_wait_timeout，长事务容易被 kill，建议每批后 COMMITJDBC 流式处理 UPDATE 的三个硬开关JDBC 本身不支持“流式 UPDATE”，但你可以通过控制查询 + 更新的节奏，模拟流式行为。关键不在 SQL，而在连接配置和执行逻辑。 Julius AI Julius AI是一款功能强大的AI数据分析工具，可以快速分析和可视化复杂数据。