高并发下 JDBC 游标读大结果集：fetchSize 与连接持有时间的量化取舍

背景

我负责一条实时 ETL 管道的核心组件：从 MySQL 读 50~200 万行增量数据做转换后写回目标库。JDK 17 + HikariCP 5.1，maxSize=20。触发方式是定时任务 + Kafka 事件双驱动，高峰期并发读连接数可达 10~15，同时还有大量 RT 5~10ms 的小查询共享同一个池。

现象

开启 useCursorFetch=true, fetchSize=5000 后，单次读 200 万行约 45s。核心矛盾在于：这 45s 内连接一直被占住（HikariCP active 计数不降）。高峰期若 3 个大查询同时触发，20 个连接立刻只剩 5 个可用，其他小查询（正常 P99 12ms）开始排队等连接，P99 飙到 800ms+。但如果不开游标、一次性拉全量，200 万行直接 OOM。

已尝试的排查与结果

1. fetchSize=1000：内存降了，但读 200 万行耗时翻倍到 90s+，连接占用时间更长，P99 更差；
2. 拆成 4 次 × 50 万行分批读：每次占用降到 ~12s，但批间空窗导致 leakDetectionThreshold 频繁告警，且 4 次读之间的"拿-放-再拿"增加了连接池抖动；
3. 大查询独立连接池（maxSize=5）做隔离：可行但多维护一套池，且大查询之间仍会互抢，小查询池也要预留余量给偶发大查询；
4. 查了 MySQL Connector/J 6.x/8.x 的 server-side cursor 文档，发现 useCursorFetch 在 5.1 和 8.x 行为有差异（8.x 默认走 useServerPrepStmts 路径），但官方文档没写清楚 fetchSize 对 server-side cursor 的实际生效逻辑。

期望得到的答案

1. 有没有人在生产里跑过「游标读大结果集 + 高并发小查询共享同一连接池」的方案？具体怎么配的（fetchSize、maxSize、是否独立池、leakDetection 阈值）？
2. 如果必须共享池，fetchSize、maxSize、并发大查询数三者之间有没有一个量化的决策框架或经验公式？比如"大查询并发数 × 预估持有时间 ≤ maxSize × 可接受排队时间"这类；
3. MySQL Connector/J 8.x 的 server-side cursor 跟 5.1 的 useCursorFetch 行为差异，你们踩过什么坑？fetchSize 到底控制的是"每次从服务端拉多少行"还是"JVM 端 buffer 大小"？
4. 除了拆批次和独立池，还有没有更优雅的方式把"长连接持有"的影响隔离掉？比如异步流式读 + 背压、或者用 MySQL 的 LOAD DATA OUTFILE 绕开 JDBC 连接？

最好能带上具体的 JDBC URL 参数、HikariCP 配置片段或线上监控截图，谢谢。