必须关闭 connection.setAutoCommit(false)，否则 Oracle JDBC 批量更新退化为单条执行，性能崩盘且易锁表；需手动 commit()/rollback()，分批控制在 500–5000 行，用 PreparedStatement.addBatch() 并 clearBatch()，禁用 Statement 拼接，优先 ROWID 更新，分页用 ROWNUM 或 OFFSET FETCH，多线程需独占连接与数据分片。
必须关闭 connection.setAutoCommit(false)
oracle jdbc 批量更新不关自动提交，addbatch() 就是白忙——它只缓存在 preparedstatement 内部，等你调用 executebatch() 才真正发包；但驱动默认开启 autocommit，一执行就隐式 commit，批量退化成单条，性能崩盘还容易锁表。
显式关闭后，必须配套手动 commit() 或 rollback()，否则连接长期挂起，可能被连接池回收或阻塞其他事务。
- 别在 finally 块里无条件
commit()：出异常时该回滚，不是硬提交 - 若用连接池（如 HikariCP），确保连接未被提前归还；建议用
try-with-resources管理PreparedStatement，但Connection生命周期需自己把控 - 事务太长会撑大 UNDO 表空间，单批控制在 500–5000 行较稳妥（视单行数据大小和索引复杂度而定）
PreparedStatement.addBatch() 是唯一安全入口
别用 Statement.addBatch() 拼 SQL 字符串——Oracle 对动态拼接批量语句支持极差，极易触发绑定变量缺失、硬解析爆炸、ORA-01000（游标超限）等问题。
必须用 PreparedStatement，占位符统一，驱动才能复用执行计划。注意两个典型坑：
-
SQL字符串末尾不能带分号，否则必报ORA-00911: invalid character；例如"UPDATE t SET x = ? WHERE id = ?;"要改成"UPDATE t SET x = ? WHERE id = ?" - 循环中复用同一
PreparedStatement时，每次executeBatch()后建议显式调用clearBatch()，避免旧批次残留干扰下一轮 - 批量太大（如单次 > 1000 条）易触发 JVM 堆内存压力或 Oracle 游标上限，推荐每 500 条
executeBatch()一次，再clearBatch()
千万级必须分批拉取 + 分批更新，不能全查进内存
直接 SELECT * 百万行进 ResultSet，JVM 很快 OOM；Oracle 端也会因 PGA 过载触发 ORA-04030。正确做法是服务端分页拉取 + 客户端分批更新双结合。
推荐用 ROWNUM 或 OFFSET FETCH（Oracle 12c+）切片，每次最多取 10000 行（setFetchSize(10000) 可减少网络往返），处理完立即更新并 commit()：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
String sql = "SELECT rowid, id, status FROM users WHERE status = 'D' AND ROWNUM
- 用
ROWID更新比主键更高效，尤其在无合适索引时；但注意ROWID在表移动、分区分裂后会失效，生产环境需评估稳定性 - 避免在 SQL 中写死
WHERE ... AND ROWNUM 做分页，它无法跳过前 N 行；真要跳页得用嵌套查询或OFFSET - 如果更新条件本身能走索引，且数据分布均匀，可考虑按主键范围分片（如
id BETWEEN ? AND ?），更可控
多线程并行更新要防连接/事务/资源争用
单线程跑千万级更新太慢，但盲目开多线程容易翻车：连接数爆满、UNDO 表空间抢夺、甚至死锁。关键不是线程数越多越好，而是让每个线程独占连接 + 独立事务 + 数据互斥。
实操建议：
- 每个线程持有一个独立
Connection（从连接池获取，用完 close 归还），不要共享 connection 或 statement - 数据分片必须不重不漏：用主键/ROWID 区间划分，或预生成分片 ID 列表（如先查出所有待更新
ROWID存入临时表，再用ROWNUM分配给各线程） - 线程数建议 ≤ 数据库 CPU 核数 × 2；超过反而因上下文切换和锁竞争拖慢整体速度
- 加监控：捕获
SQLException中的getErrorCode()，重点拦截ORA-00060（死锁）、ORA-01555（快照过旧）等，失败批次应记录日志并可重试
最易被忽略的是：分批 commit 后，UNDO 段不会立刻释放，高并发下可能快速耗尽；务必确认数据库 UNDO_RETENTION 设置合理，并观察 v$undostat 视图。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
