// 💥 翻车现场：经典“单线程+全量加载”的自杀式报表生成String sql = “SELECT province, sum(amount), count(distinct user_id) FROM t_trade … GROUP BY province”;ListMapString, Object result = jdbcTemplate.queryForList(sql); // 💥 5亿行数据直接塞进 JVM 堆！exportToExcel(result);结果呢？SQL 刚发出去，达梦数据库的 CPU 单核直接打满 100%（其他 63 个核在看戏），跑了 20 分钟还没出结果。接着，Java 端的 JVM 因为接收了海量的 ResultSet 数据，直接触发 Full GC，随后 java.lang.OutOfMemoryError: Java heap space，Pod 被 K8s 无情重启！DBA 看着监控图冷笑：“Java 内存太小了，加机器！”Java 开发拍桌子：“达梦太慢了，单核跑了 20 分钟，换个 Oracle Exadata 试试？”我盯着达梦的执行计划和 Java 的 GC 日志，血压直接飙到 180。我拍着他们的桌子吼：“你们这是在用单缸拖拉机去拉高铁的货啊！达梦服务器 64 个核，你们只让它跑 1 个线程；Java 端用单连接同步阻塞接收，网络带宽全被浪费！不用达梦的并行查询（Parallel Query），不用 Java 21 的虚拟线程做分片拉取，这报表跑到明年也出不来！”那之后，我带着团队闭关一周，把达梦的并行执行引擎源码扒了个底朝天，结合 Java 2
// 💥 翻车现场：经典“单线程+全量加载”的自杀式报表生成String sql = “SELECT province, sum(amount), count(distinct user_id) FROM t_trade … GROUP BY province”;ListMapString, Object result = jdbcTemplate.queryForList(sql); // 💥 5亿行数据直接塞进 JVM 堆！exportToExcel(result);结果呢？SQL 刚发出去，达梦数据库的 CPU 单核直接打满 100%（其他 63 个核在看戏），跑了 20 分钟还没出结果。接着，Java 端的 JVM 因为接收了海量的 ResultSet 数据，直接触发 Full GC，随后 java.lang.OutOfMemoryError: Java heap space，Pod 被 K8s 无情重启！DBA 看着监控图冷笑：“Java 内存太小了，加机器！”Java 开发拍桌子：“达梦太慢了，单核跑了 20 分钟，换个 Oracle Exadata 试试？”我盯着达梦的执行计划和 Java 的 GC 日志，血压直接飙到 180。我拍着他们的桌子吼：“你们这是在用单缸拖拉机去拉高铁的货啊！达梦服务器 64 个核，你们只让它跑 1 个线程；Java 端用单连接同步阻塞接收，网络带宽全被浪费！不用达梦的并行查询（Parallel Query），不用 Java 21 的虚拟线程做分片拉取，这报表跑到明年也出不来！”那之后，我带着团队闭关一周，把达梦的并行执行引擎源码扒了个底朝天，结合 Java 2
