在简单静态方法查询中使用PreparedStatement是否具备性能优势？

场景背景 #

你提到有一个用于检查数据库中ID是否存在的静态方法，原始实现是通过字符串拼接SQL使用Statement：

public static boolean isPersisted(Integer id) { 
    String sql = "select id from table where id = "+id+""; 
    // 省略后续执行逻辑
}

你清楚PreparedStatement的SQL注入防护能力，也了解它在批量操作场景下的优势，但在这种单次、单参数的简单查询场景中，不确定它是否有性能或内存层面的优势。调研时看到很多笼统的结论，却没有针对该场景的明确答案，于是你做了针对性的性能测试。

测试环境与方案 #

为保证测试严谨性，你基于以下环境开展测试：

• JDK版本：Java 1.8
• JDBC驱动：ojdbc8.jar
• 数据库：Oracle 12C（非生产环境，仅你一个用户使用）

测试方案设计：

• 共执行10轮测试，每轮包含100次查询
• 每轮中50次使用PreparedStatement（预编译SQL后执行），50次使用Statement（字符串拼接SQL后执行）
• 为排除数据库缓存对结果的干扰，特意调换执行顺序（先执行Statement再执行PreparedStatement）重新测试

测试结果 #

从你给出的测试数据（单位：毫秒，包含平均值与标准差）来看：
无论执行顺序如何调整，PreparedStatement的性能始终比Statement慢约25%，执行顺序对最终结果没有显著影响。

结果解读 #

在这种单次、简单参数的查询场景下，出现这个结果是合理的：

• PreparedStatement的核心优势之一是预编译后的执行计划可以被复用，但在单次执行的场景下，预编译带来的额外开销无法被后续复用摊销，反而成为性能负担
• Statement通过字符串拼接直接生成完整SQL，跳过了预编译步骤，在单次执行时减少了额外处理环节，因此表现更优
• 这里需要特别提醒：安全性优先级永远高于性能。如果isPersisted方法的id参数来自不可信的外部输入，Statement的字符串拼接方式会存在严重的SQL注入风险，此时无论性能差异多大，都应该优先使用PreparedStatement

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