多线程通过不同游标分块更新百万级数据表的性能瓶颈排查问询

1. 数据库IO与查询开销成为饱和点 #

你用到的OFFSET X FETCH FIRST Y其实是个隐形的性能陷阱：当X值越大时，数据库需要先扫描并跳过前X条记录才能定位到目标数据段——比如最后一个线程要跳过90万条才能取到10万条，这个扫描过程本身就会消耗大量磁盘IO和数据库CPU资源。当多个线程同时执行这类查询时，数据库的磁盘读IO会迅速被占满：哪怕你的应用端有空闲CPU，但数据库已经没有多余的IO能力来处理更多并行请求了，这就导致线程数增加到一定程度后，整体性能不再提升。

另外，每个线程都创建独立的数据库连接，虽然你有12个空闲处理器，但数据库的连接池、后台线程调度、锁资源也会因为并发数上升而出现竞争，进一步拖慢响应速度。

2. 更新操作的日志写入瓶颈 #

你的代码里是每行执行rs.updateRow()，这意味着每更新一条记录就会触发一次事务日志（WAL）的写入。当多个线程同时进行大量更新时，数据库的事务日志写入会变成瓶颈——哪怕是顺序写，高并发下的日志刷盘操作也会让所有线程进入等待状态，因为数据库必须保证日志持久化后才能确认更新完成。这种情况下，增加线程数只会让更多线程等待日志写入，无法提升整体处理速度。

3. 计算任务的CPU密集度可能被高估 #

你说这是“耗时的Java数学运算”，但实际情况可能是：运算本身并没有那么消耗CPU，线程的大部分时间都花在等待数据库的查询结果、等待更新操作完成上。这种情况下，应用端的CPU其实是空闲的，但数据库已经饱和了，所以增加线程数只是增加了等待队列的长度，并没有真正利用到更多的处理器资源。

4. 数据拆分的不均或隐性同步问题 #

虽然你按10万条拆分数据，但OFFSET的方式可能导致不同线程的查询耗时差异很大（比如后面的线程查询更慢），整个任务的完成时间由最慢的那个线程决定。另外，如果你的数学运算不小心共享了某个非线程安全的计算工具类，也会导致多线程下出现锁竞争，抵消并行带来的收益。

• 替换OFFSET分页为范围查询：用主键（比如ID）来拆分数据，比如每个线程查询WHERE ID BETWEEN start AND end，利用主键索引快速定位数据，避免OFFSET带来的全表扫描开销。
• 批量更新代替单行更新：收集一批计算后的结果，然后用UPDATE DATA SET COL = ? WHERE ID = ?的批量更新语句，减少数据库交互次数和日志写入压力。
• 检查数据库性能指标：如果能拿到数据库的监控数据，重点看磁盘IO使用率（读/写）、CPU使用率、事务日志写入速度、锁等待次数——这些数据能直接告诉你是不是数据库资源已经饱和。
• 测试纯计算的并行性：先把所有数据读到内存中，然后多线程执行数学运算，看性能是否随线程数提升。如果提升明显，说明瓶颈在数据库；如果还是不提升，那可能是计算任务本身的问题（比如不是CPU密集型，或者有同步瓶颈）。

内容的提问来源于stack exchange，提问作者Sfp