DB2批量查询性能异常：50条耗时29秒，55-60条需20分钟

你遇到的这个情况太典型了——小批量数据时性能正常，一旦到某个阈值（55-60条）就突然变慢，本质是小数据量掩盖了累积的性能瓶颈，到临界点后所有开销一次性爆发。我给你拆解几个最可能的原因和对应的解决办法：

1. 每次循环新建数据库连接（最常见的坑） #

如果你的代码是处理一条卡号就新建一次DB2连接、查完就关，前50条的时候系统连接资源还充足，开销没显现；但到55+条时，要么连接池被耗尽导致等待，要么反复创建/销毁连接的累积开销直接拉垮性能。

解决办法：复用连接 #

提前初始化一个数据库连接（或者用连接池，比如HikariCP），整个批量处理过程复用这一个连接，处理完所有记录后再关闭。伪代码示例：

// 初始化连接（放在循环外面！）
Connection conn = DB2ConnectionHelper.getPooledConnection();
try {
    for (String cardNumber : cardDataArray) {
        // 用同一个conn执行查询
        String sql = "SELECT * FROM your_table WHERE card_number = ?";
        PreparedStatement pstmt = conn.prepareStatement(sql);
        pstmt.setString(1, cardNumber);
        ResultSet rs = pstmt.executeQuery();
        
        // 处理查询结果、和文本数据比对
        // ...
        
        rs.close();
        pstmt.close();
    }
} finally {
    // 所有记录处理完再关闭连接
    conn.close();
}

2. 用字符串拼接SQL导致重复硬解析 #

如果你的查询是直接拼接卡号（比如"SELECT * FROM table WHERE card = '" + cardNum + "'"），每条不同的卡号都会让DB2重新解析SQL、生成执行计划。前50条时缓存还能扛，但到一定数量后，硬解析的CPU开销会急剧上升。

解决办法：用参数化查询 #

一定要用PreparedStatement做参数化查询，让DB2只解析一次SQL，后续复用执行计划，这能大幅降低CPU消耗——上面的伪代码已经用了这种方式，别再手动拼字符串了！

3. 唯一卡号字段没有索引 #

如果你的card_number字段没建索引，每次查询都是全表扫描。当表数据量大时，50次全表扫描可能还快，但55+次时，刚好触发磁盘缓存淘汰，需要从磁盘读数据，IO开销直接爆发。

解决办法：给卡号建唯一索引 #

因为卡号是唯一标识，直接建唯一索引：

CREATE UNIQUE INDEX idx_unique_card ON your_table(card_number);

建完索引后，查询会从全表扫描变成索引查找，速度能提升几个数量级。

4. 用批量查询替代单条查询（进阶优化） #

哪怕解决了上面的问题，单条查询50+次还是有网络交互开销。不如把所有卡号一次性传给DB2，减少往返次数。

两种实现方式： #

方式1：用IN子句批量查询

// 生成参数占位符，比如50条就生成50个?
String placeholders = String.join(", ", Collections.nCopies(cardDataArray.size(), "?"));
String sql = "SELECT * FROM your_table WHERE card_number IN (" + placeholders + ")";

PreparedStatement pstmt = conn.prepareStatement(sql);
// 给每个占位符赋值
for (int i = 0; i < cardDataArray.size(); i++) {
    pstmt.setString(i + 1, cardDataArray[i]);
}

ResultSet rs = pstmt.executeQuery();
// 一次性获取所有匹配的DB2数据，再和文本数据做比对
// ...

方式2：临时表关联查询（适合超大量数据）

如果后续数据量还要涨，用临时表效率更高：

-- 创建会话级临时表
DECLARE GLOBAL TEMPORARY TABLE session.card_list (card_number VARCHAR(30) NOT NULL) 
ON COMMIT PRESERVE ROWS;

-- 批量插入所有文本里的卡号
INSERT INTO session.card_list (card_number) VALUES (?), (?), ...;

-- 关联查询获取匹配数据
SELECT t.* FROM your_table t 
JOIN session.card_list c ON t.card_number = c.card_number;

先按这几步排查：先确认连接是不是复用了，再看有没有用参数化，最后检查索引是否存在——这三个步骤基本能解决90%的这类性能问题。

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