初看“Connection.createStatement”和“Statement/PreparedStatement”这个话题不少人会觉得老掉牙——JDBC是Java后端最基础的东西但凡写过数据库代码的人都用过。但我在这些年里经历过的两个故障让我对这两个类的理解发生了彻底的改变一次是凌晨被电话叫醒说线上订单号重复入库另一次是某同学在群里问“为什么我的SQL执行一次比一次慢日志打出来都是编译时间”。这两个问题最后都回到了Statement和PreparedStatement本身的机制上。所以这个看似简单的标题其实藏着不少值得掰开揉碎讲清楚的东西——连接层到底做了什么、预编译缓存在哪一层生效、批量操作的真正代价、以及那些网上很少被提到的边界情况。这篇文章就是把我自己踩过的坑、查过的源码、实测过的心得整理出来希望对正在写JDBC代码的你有所帮助尤其是那些已经能跑通基本CURD、但还想更进一步理解背后机制的同学。1. 从一次线上事故说起Statement和PreparedStatement的真实差别1.1 那个凌晨的SQL拼串事故那次事故的场景我至今记得很清楚某提醒服务每天凌晨要向一批用户发消息当时负责这块的同事为了快速上线直接用Statement拼了一个很大的动态SQL。本来以为只是数据量大了变慢结果用户开始收到重复消息。排查后发现之前逻辑是每次先delete某张状态表再插入新记录但因为SQL超长后触发了某种异常导致delete没有执行成功而insert还在继续最终状态表里留下了大量旧数据——顺序乱了重复消息就出来了。这里面的真正元凶就是对Statement性质的误判。用Statement的时候SQL是作为字符串整体传给数据库的每执行一次数据库都要重新解析、生成执行计划。而更关键的是一旦SQL里面拼了外部输入比如用户ID、时间范围这些输入被直接嵌入SQL文本产生的不只是性能隐患还有语义不可控的风险。那次事故中就是因为拼接出的SQL包含了一个未清理干净的分支条件实际执行的语句和预期完全不匹配导致delete被逻辑跳过。1.2 拼字符串到底错在了哪里很多人觉得拼SQL只是不优雅不觉得是技术债。但说一个最直接的例子String sql SELECT * FROM t_order WHERE user_id userId;这段代码在userId是一个普通数字时看起来一切正常。但如果userId来自一个不受信任的入口比如某人提交了一个1 OR 11拼接出来的SQL就变成了SELECT * FROM t_order WHERE user_id 1 OR 11全表数据就都暴露了。这就是SQL注入最经典的形态。你可能会说“我们的入参都是数字做了校验”可现实里很多业务字段是字符串、日期、甚至JSON片段你永远无法保证每个入口都做了严格的转义和校验。PreparedStatement处理这个问题的思路完全不同SQL骨架和参数是分开传输的数据库在编译阶段就把?当作参数占位符之后再用实际值去填充。这句话有两层意思一是SQL结构在编译时就被固定了用户输入永远只是“数据”而不可能变成“指令”二是同一个SQL模板只需要编译一次后续重复执行时直接复用执行计划省掉了重复解析的开销。1.3 用一张表看清Statement和PreparedStatement的差异对比维度StatementPreparedStatementSQL编译每次执行都完整解析、编译首次编译后缓存执行计划重复执行直接复用参数传递拼接进SQL文本靠转义自求多福通过占位符传参驱动自动处理类型转换SQL注入风险高取决于开发者是否做了严格的过滤、转义低参数不会改变SQL语义批量执行需逐条发送SQL文本网络开销大支持预编译批处理可显著减少通信与解析成本可读性与维护性长字符串拼接读起来费劲模板与参数分离代码结构清晰类型安全全部变成字符串强制转换容易出错驱动会按参数类型做相应处理减少转型问题注意PreparedStatement也不是绝对保险比如错误地使用字符串拼接来构造SQL模板本身或者在某些驱动版本中参数类型与数据库列类型不匹配导致隐式转换依然可能带来意外。但相比Statement它把风险降到了很低的量级。2. 说透Connection.createStatement背后的设计逻辑2.1 拿到Statement之前连接层做了什么用JDBC执行一条SQL第一步永远是取得Connection。而Connection.createStatement()这个调用很多人没有仔细想过它的开销。它并不是简单地“取一个现成的对象”而是经过了一系列步骤首先是连接池获取连接。如果用的是HikariCP这类池化组件这一步大多数时候是复用已有连接开销很低。但如果没有连接池每次new一个连接都要经过TCP握手、认证、会话初始化等流程这个成本可能达到几十甚至上百毫秒比执行一条简单SQL还贵。然后是Driver层的处理。调用createStatement时驱动会返回一个Statement对象但它本质上是和这条连接绑定的。驱动内部可能还会懒加载一些元数据、设置会话变量、准备结果集游标等。不同驱动实现各有差异MySQL Connector/J和PostgreSQL JDBC Driver的处理就不完全一样但共同点是这个环节有开销而且连接的状态会影响创建Statement的成本。再说说自动提交。默认情况下JDBC连接是自动提交模式autoCommit true也就是说你每执行一条SQL数据库都会立即提交事务。这个机制在单条SQL场景下很简单但在一个业务方法里执行多条UPDATE时就会产生多次事务提交每一次提交都要刷写日志、释放锁性能损耗非常明显。所以早年的实践往往都会在执行多条语句之前先调用connection.setAutoCommit(false)最后统一commit。2.2 Statement的三种基础操作拿到Statement之后最常用的三个方法就是executeQuery、executeUpdate和execute。executeQuery用于执行SELECT返回的是ResultSet这个对象承载查询结果。注意ResultSet并不是一次性把所有数据拉到内存而是一般通过流式方式从数据库逐行读取不同驱动实现细节不同。这意味着如果查询返回了海量数据但你没有及时关闭ResultSet连接和数据库端的游标资源就会被长期占用。executeUpdate用于INSERT、UPDATE、DELETE等DML操作返回的是受影响的行数。很多人忽略的细节是某些数据库甚至某些版本的驱动对executeUpdate返回的“行数”语义有歧义尤其是在批量操作时返回的是每批的行数还是累计行数需要实测确认。execute是一个通用方法SELECT和DML都能执行。如果SQL是SELECT返回值为true需要通过getResultSet拿结果集如果是DML返回值为false需要靠getUpdateCount获取受影响行数。这个方法的定位在于SQL类型不确定的场景比如动态生成的工具类。还有一个容易被忽略的点——所有Statement对象在数据库层面最终都会对应一个游标或执行句柄。如果创建了Statement但对结果集只处理了一半就丢到一边既没有关闭Statement也没有关闭ResultSet长此以往连接池里的连接会被这些“半死状态”占满新请求拿不到连接业务就挂了。2.3 ResultSet游标和数据类型转换ResultSet的游标机制恰恰解释了为什么那句“数据集从数据库取到本地”的说法不准确。默认情况下Type为TYPE_FORWARD_ONLYConcurrency为CONCUR_READ_ONLY也就是只能向前移动、只读。这已经覆盖了绝大多数业务场景。但在某些特殊场景下比如你需要在一个事务里先查询再更新某一行很多人会下意识想用ResultSet去updateRow。这时就要确认驱动的ResultSet到底是否支持可滚动、可更新。MySQL的驱动默认是不支持的强制使用很容易抛异常。更合理的做法是查出主键后另起一条UPDATE语句而不是试图在ResultSet上直接改。数据类型转换也是坑。数据库里的DECIMAL、BIGINT、DATETIME通过getString获取时驱动会做转换但有些转换会导致精度损失尤其是BIGINT超过Long.MAX_VALUE时或者DATETIME在不同时区下的显示值不一样。通常我建议按列的真实类型去取数据能取Long就不取String能用LocalDateTime就不硬拼字符串。3. 为什么生产环境几乎见不到裸Statement3.1 预编译的执行路径PreparedStatement的好处官网文档和各类教程都说了很多但我想从执行路径的角度讲一下。在MySQL Connector/J中PreparedStatement的执行过程大概是这样的客户端把SQL模板和参数通过二进制协议发送到服务端服务端先解析SQL并生成执行计划将执行计划缓存起来之后如果相同的SQL模板再次到达就可以直接使用缓存的执行计划而不用再解析一遍。但这里有一个隐藏关键点并不是所有“看起来一样”的SQL都能命中缓存。SQL文本必须完全一致包括大小写、空格、换行。比如SELECT * FROM t_user WHERE id ?和SELECT * FROM t_user WHERE id? -- 注意少了空格或者是全大写在大部分数据库里被认为是不同的SQL所以缓存就失效了。很多人喜欢用工具自动格式化SQL在开发环境看着舒服但如果在代码里通过模板引擎拼接SQL格式不统一就会导致预编译形同虚设。更隐蔽的问题是MySQL默认对PreparedStatement的预处理是“客户端模拟”的。MySQL Connector/J里面有一个参数useServerPrepStmts默认是false。也就是说如果不显式开启PreparedStatement的占位符是在客户端完成的SQL并没有真正发送到服务端做预编译。这种情况下防注入的能力依然有效但性能收益会打折扣。生产环境中如果希望真正利用服务端预编译通常需要jdbc:mysql://localhost:3306/test?useServerPrepStmtstruecachePrepStmtstrue开启cachePrepStmts后驱动会在客户端缓存PreparedStatement句柄避免重复请求服务端创建预编译语句。这个参数的影响在我实测的项目里语句重复执行上百次时整体耗时能降低20%以上尤其是复杂SQL。但也不是越大越好假如每个业务方法都构造自己独有的SQL文本缓存里会积累大量无用的预编译语句反而增加内存压力。3.2 性能差异的定量感受很多同学问用Statement重复插入1000条记录和用PreparedStatement批量插入差距到底有多大我做过一个简单的对比测试本机数据库插入1000条数据每条数据10个字段左右。用Statement逐条拼接执行耗时大约800毫秒到1秒用PreparedStatement逐条执行耗时大约600到700毫秒用PreparedStatement的批量模式addBatch executeBatch耗时能压缩到100毫秒左右。为什么批量模式这么快因为减少了网络往返次数。逐条插入时每条数据都要发送一个完整的请求1000条就是1000次往返批量模式可以把1000条数据的参数一次性打包发送当然驱动内部会按阈值分批网络通信次数大幅减少。还有一个原因是每条SQL的编译工作只做一次后续执行计划复用。这个测试说明PreparedStatement并不只是安全性的选择更是性能和资源利用的选择。尤其是你的业务中频繁执行结构相同、参数不同的SQL时预编译的收益相当可观。3.3 用PreparedStatement的正确姿势用法上和我见过很多半路出家的代码对比有几个容易被忽略的细节占位符是1-based——?的下标从1开始不是0。这个错误藏在代码里非常隐蔽因为大多数时候你只在JDBC代码里和下标打交道一旦列多、条件长、动态SQL复杂越界和错位几乎是必然。我的建议是动态条件多时先把条件和参数分别存入List再按顺序绑定。参数类型要用setObject还是setString—— 新手习惯setString(1, value)但对于日期、数字、Boolean这种字段setString会让数据库做一次隐式类型转换可能无法命中索引。正确的做法是按Java类型选择setInt、setLong、setTimestamp、setBigDecimal等方法。如果字段类型确实不确定可以用setObject驱动会按照Java对象的类型去映射。不要在一次执行中反复设置同一参数—— 很多人会在循环里重新调用setString其实这是允许的但要注意有些驱动会检查参数是否变更频繁变更本身也会增加额外的状态同步开销。更合理的做法是循环内部尽量只修改必要的参数或者直接复用已经绑定好的参数。用完就关别靠GC—— Statement、ResultSet、Connection这三个对象的关闭顺序也很讲究。最标准的做法是在try-with-resources中逆序声明先声明Connection再声明PreparedStatement最后声明ResultSet。这样当try块结束时关闭顺序正好是ResultSet → Statement → Connection不会出现“连接忘了关”的问题。4. 实操用PreparedStatement完成一整套数据库操作4.1 基础增删改查的代码骨架直接给出一套常见的基础代码注释里写清楚每一步的含义public ListUserDO listUsers(Date startTime, Date endTime) { String sql SELECT id, name, created_at FROM t_user WHERE created_at BETWEEN ? AND ?; ListUserDO users new ArrayList(); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { // 占位符从1开始第一个?对应startTime第二个?对应endTime ps.setTimestamp(1, new Timestamp(startTime.getTime())); ps.setTimestamp(2, new Timestamp(endTime.getTime())); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { UserDO user new UserDO(); user.setId(rs.getLong(id)); user.setName(rs.getString(name)); user.setCreatedAt(rs.getTimestamp(created_at).toLocalDateTime()); users.add(user); } } } catch (SQLException e) { // 生产环境应替换为更精细的日志和异常转换 log.error(query users failed, sql{}, startTime{}, endTime{}, sql, startTime, endTime, e); throw new RuntimeException(query user failed, e); } return users; }这段代码核心的几个点占位符和set方法一一对应try-with-resources保证了连接、语句、结果集都被正确关闭使用setTimestamp来绑定时间字段避免字符串拼接引发格式问题。看似简单但在真实项目中这些细节决定了代码是能稳健运行还是三天两头出bug。4.2 批量插入的正确写法批量插入是最能体现PreparedStatement价值的场景。在订单、日志、行为流水等数据量较大的写入场景中批量插入几乎是必修课。一个标准的写法如下public void batchInsertOrders(ListOrderDO orders) { String sql INSERT INTO t_order (order_no, user_id, amount, status, created_at) VALUES (?, ?, ?, ?, ?); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { // 关闭自动提交便于统一事务管理 conn.setAutoCommit(false); int batchSize 0; for (OrderDO order : orders) { ps.setString(1, order.getOrderNo()); ps.setLong(2, order.getUserId()); ps.setBigDecimal(3, order.getAmount()); ps.setString(4, order.getStatus()); ps.setTimestamp(5, Timestamp.valueOf(order.getCreatedAt())); ps.addBatch(); batchSize; // 每500条提交一次避免单次批处理过大导致内存占用过高 if (batchSize % 500 0) { ps.executeBatch(); } } // 提交剩余不足500条的批次 ps.executeBatch(); conn.commit(); } catch (SQLException e) { // 出错时回滚避免部分数据残留 log.error(batch insert orders failed, e); try (Connection conn dataSource.getConnection()) { conn.rollback(); } catch (SQLException ex) { log.error(rollback failed, ex); } throw new RuntimeException(batch insert orders failed, e); } }这里有几个心得。分批提交的阈值我一般设置为200到500条。太大的话单次executeBatch会占用大量内存保存参数数据太小的话又没法有效减少网络往返。另一个坑是如果某一条数据在批处理中执行失败数据库的行为取决于QO和驱动实现有的会直接中断整个批次有的会继续执行后面的还有的会抛出BatchUpdateException并携带成功数。所以捕获异常时最好把BatchUpdateException的getUpdateCounts打出来看看明确哪些成功、哪些失败。4.3 获取自增主键插入一条记录后经常需要立即拿到自增ID用Statement.RETURN_GENERATED_KEYS的写法非常方便。PreparedStatement同样支持String sql INSERT INTO t_biz (biz_name) VALUES (?); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, bizName); ps.executeUpdate(); try (ResultSet rs ps.getGeneratedKeys()) { if (rs.next()) { Long id rs.getLong(1); return id; } } }但要注意getGeneratedKeys的有效性和数据库/驱动强相关。MySQL是支持的PostgreSQL也能用但某些老版本的驱动或某些中间件可能拿到空结果。如果项目本身是双数据库兼容我建议用规范的SQL查询方式回查一遍主键而不是完全依赖这个功能。另外如果插入语句里指定了主键值那getGeneratedKeys大概率返回空这是常见误解。4.4 动态查询条件组合动态SQL在业务系统中太常见了但很多人还是抱着“拼接字符串”的思维去写。PreparedStatement的动态SQL要稍微绕一下但思路很明确先用List收集条件片段和参数再一次性生成SQL。public ListUserDO search(String name, Integer minAge, Integer maxAge) { StringBuilder sql new StringBuilder(SELECT id, name, age FROM t_user WHERE 1 1); ListObject params new ArrayList(); if (StringUtils.hasText(name)) { sql.append( AND name LIKE ?); params.add(% name %); } if (minAge ! null) { sql.append( AND age ?); params.add(minAge); } if (maxAge ! null) { sql.append( AND age ?); params.add(maxAge); } try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql.toString())) { for (int i 0; i params.size(); i) { ps.setObject(i 1, params.get(i)); } try (ResultSet rs ps.executeQuery()) { // 处理结果... } } }这里的核心是“参数和条件同步收集”这样就避免了在拼接SQL时还要重新数占位符的尴尬。条件一多这种写法尤其省心。注意LIKE语句中%和_是放在参数里拼接的不能在SQL模板里直接写否则占位符会被通配符干扰查询结果和预期完全不一样。5. 常见坑与排查实录5.1 连接泄漏——我见过最普遍的事故连接泄漏是所有使用Connection的程序员的噩梦它的表现不是“立刻报错”而是“运行几天后突然大量超时”。我见到过的典型场景某同学在方法里获取了Connection但忘记在finally里关闭因为平时流量小看不出问题一旦流量上来连接池的可用连接被占满新请求全部排队最终触发了雪崩效应。排查方法很简单开启连接池的泄漏检测。HikariCP可以配置leakDetectionThreshold比如设为10000毫秒连接从池中借出超过这个时间没有归还日志里就会打印一段带堆栈的警告那一段堆栈能直接定位到是哪一行代码借了连接没还。这个方法救过我好几次强烈建议线上开启代价是微乎其微的性能开销。另一个防止连接泄漏的实践是避免在try块里手动close而是使用try-with-resources。但要说清楚try-with-resources只能保证“声明在try括号里的资源”被关闭如果你在方法内部先获取了Connection然后又传给另一个方法去执行SQL关闭的责任就要被清晰定义否则很容易出现“我关了你还在用”的异常或者反过来“你没关你也不管”的泄漏。5.2 where in 参数占位符失效很多人在SQL里写WHERE id IN (?)然后试图用setString把一组ID传进去结果发现只匹配到一条数据甚至报错。原因很简单JDBC的占位符是“一个占位符对应一个值”并不是“一个占位符对应一个列表”。我一般推荐两种方案。第一种是动态生成占位符串ListLong ids Arrays.asList(1L, 2L, 3L); String placeholders ids.stream().map(id - ?).collect(Collectors.joining(,)); String sql SELECT * FROM t_user WHERE id IN ( placeholders );这种方式直白且兼容性好。注意IN子句的列表不宜过长否则不仅SQL文本变大数据库执行计划也可能退化。超过1000个ID时我一般会分批查询或者改用临时表关联。第二种方案是对接一些高级特性比如PostgreSQL的数组类型、MySQL的JSON_CONTAINS但前提是你的数据库版本和驱动都支持而且不能为了用特性而牺牲可移植性。5.3 大结果集吃内存ResultSet默认是一次性把数据拉回客户端吗其实不一定。MySQL驱动在处理大结果集时有useCursorFetch参数。默认情况下MySQL是边读边取的但如果你执行了一条返回十万行的查询又不想全部加载到内存可以考虑设置statement.setFetchSize(Integer.MIN_VALUE)这会启用流式读取逐行从服务端取数代价是读取期间不能执行其他语句某些版本lock了连接。很多做报表导出、大批量数据同步的同学在这块踩坑最多。明明查了几万行数据就把内存打满其实就是没有显式设置fetchSize驱动可能是把结果一次性拉到了客户端。解决方式要先确认驱动行为再去设fetchSize不要想当然。5.4 事务超时与自动提交误区事务和Statement的关系很多人理解是“事务就是多条SQL放在一起”。但一个容易忽视的点是在JDBC里事务边界由Connection控制而不是由Statement控制。如果在一个方法里打开事务先执行了INSERT中途抛了异常但你只关闭了Statement没有回滚这个事务可能一直挂着占着数据库连接和锁资源。更糟糕的误操作是把setAutoCommit(false)和commit写进了循环里。每调一次commit事务就结束了后续SQL自动开启新事务。如果业务上需要“全部成功或全部失败”这种写法是灾难。我见过一个定时任务就是因为循环里commit导致前面一批数据处理成功、后面失败时无法回滚最终产生了数据不一致。建议把事务管理放到独立的层比如Spring的Transactional避免自己在业务代码里散落地调用setAutoCommit和commit这样不仅清晰也容易被框架的统一机制兜底。5.5 预编译缓存被撑爆服务端预编译虽然好但如果你在SQL模板里拼接了很多不同的字符串值比如把表名、字段名、排序字段也拼进去那缓存里会有成千上万个不同的SQL模板内存和解析开销都上来了。这种情况下你不仅没享受到预编译的复用收益反而比Statement更糟。我的一个习惯是表名、字段名、排序字段这些“SQL结构”部分最好通过白名单的方式去映射不要直接用外部参数拼接。比如前端传一个orderBy字段代码里就做一个Map映射只允许白名单里的值进入SQL其他值一律用默认排序。这样既安全又保证了SQL模板的数量可控。5.6 一个容易被忽略的参数绑定顺序问题之前说过占位符从1开始这里再补充一个实战细节。在动态SQL中如果你先检查A条件再检查B条件那么参数绑定的顺序也必须严格按照条件出现的顺序来。代码里第一次写时A条件在前面B条件在后面后来有人调整了条件的先后顺序但忘了调整参数List的添加顺序结果就是查询结果完全错乱而且不会报错。这种bug极其隐蔽排查时最好的办法是在日志里把最终SQL和绑定的参数一起打出来肉眼对一遍。6. 一些长期实践下来的心得体会6.1 建议的代码组织方式围绕Statement和PreparedStatement我建议项目里往这几个方向去建设统一SQL管理SQL不要散落在业务代码里尽量收拢到DAO层的常量或XML中方便审计和优化。统一异常处理JDBC抛出的SQLException信息很笼统建议包装成带SQL、参数、错误码的领域异常方便定位。统一参数绑定如果项目里没有用ORM框架可以封装一个简单的JdbcHelper内部统一管理占位符绑定和资源关闭避免每个方法都重复写try-with-resources模板。适当引入ORM当项目复杂到一定程度纯手写JDBC的维护成本会非常高这时选用成熟的ORM框架比如MyBatis或Spring JdbcTemplate并不丢人但底层原理仍然是今天讲到的这些内容。6.2 需要避开的几个“反模式”用Statement拼接用户输入除了教学Demo我建议生产代码里完全杜绝。为了图省事统一setString导致索引失效。该setInt就setInt该setTimestamp就setTimestamp。在一个方法里创建多个Statement对象。比如先查一次再插入一次再查一次你完全可以用同一个Statement执行多条SQL当然不同预处理语句除外没必要每条SQL都创建新对象白白增加驱动和数据库的开销。企图修改ResultSet里的值来更新数据库。这个在多数驱动里是不支持的即便支持也容易引发并发问题不是一个好的实践。忽视数据库和驱动的版本差异。同一个功能在不同版本的MySQL驱动上行为可能不同比如getGeneratedKeys、服务端预编译、大结果集流式读取升级驱动后要重点回归。6.3 写在最后的一点体会我个人在实际项目里的感受是Connection.createStatement这行代码本身没有任何问题它不是洪水猛兽但它只是一个起点。真正让你少加班的是你对Statement机制的理解深度——你清楚参数如何绑定、执行计划如何缓存、连接和事务的边界在哪里你才能在遇到诡异的线上故障时迅速判断问题是出在SQL本身、连接状态、还是驱动行为上。这些年修复过的很多看似神秘的数据库问题追根究底大部分都绕不开今天聊的这几个细节。希望这篇总结能帮你少走一些弯路也欢迎你在自己的项目里实测一下批量模式的性能提升实践出来的结论比任何文档都可靠。
初看“Connection.createStatement”和“Statement/PreparedStatement”这个话题不少人会觉得老掉牙——JDBC是Java后端最基础的东西但凡写过数据库代码的人都用过。但我在这些年里经历过的两个故障让我对这两个类的理解发生了彻底的改变一次是凌晨被电话叫醒说线上订单号重复入库另一次是某同学在群里问“为什么我的SQL执行一次比一次慢日志打出来都是编译时间”。这两个问题最后都回到了Statement和PreparedStatement本身的机制上。所以这个看似简单的标题其实藏着不少值得掰开揉碎讲清楚的东西——连接层到底做了什么、预编译缓存在哪一层生效、批量操作的真正代价、以及那些网上很少被提到的边界情况。这篇文章就是把我自己踩过的坑、查过的源码、实测过的心得整理出来希望对正在写JDBC代码的你有所帮助尤其是那些已经能跑通基本CURD、但还想更进一步理解背后机制的同学。1. 从一次线上事故说起Statement和PreparedStatement的真实差别1.1 那个凌晨的SQL拼串事故那次事故的场景我至今记得很清楚某提醒服务每天凌晨要向一批用户发消息当时负责这块的同事为了快速上线直接用Statement拼了一个很大的动态SQL。本来以为只是数据量大了变慢结果用户开始收到重复消息。排查后发现之前逻辑是每次先delete某张状态表再插入新记录但因为SQL超长后触发了某种异常导致delete没有执行成功而insert还在继续最终状态表里留下了大量旧数据——顺序乱了重复消息就出来了。这里面的真正元凶就是对Statement性质的误判。用Statement的时候SQL是作为字符串整体传给数据库的每执行一次数据库都要重新解析、生成执行计划。而更关键的是一旦SQL里面拼了外部输入比如用户ID、时间范围这些输入被直接嵌入SQL文本产生的不只是性能隐患还有语义不可控的风险。那次事故中就是因为拼接出的SQL包含了一个未清理干净的分支条件实际执行的语句和预期完全不匹配导致delete被逻辑跳过。1.2 拼字符串到底错在了哪里很多人觉得拼SQL只是不优雅不觉得是技术债。但说一个最直接的例子String sql SELECT * FROM t_order WHERE user_id userId;这段代码在userId是一个普通数字时看起来一切正常。但如果userId来自一个不受信任的入口比如某人提交了一个1 OR 11拼接出来的SQL就变成了SELECT * FROM t_order WHERE user_id 1 OR 11全表数据就都暴露了。这就是SQL注入最经典的形态。你可能会说“我们的入参都是数字做了校验”可现实里很多业务字段是字符串、日期、甚至JSON片段你永远无法保证每个入口都做了严格的转义和校验。PreparedStatement处理这个问题的思路完全不同SQL骨架和参数是分开传输的数据库在编译阶段就把?当作参数占位符之后再用实际值去填充。这句话有两层意思一是SQL结构在编译时就被固定了用户输入永远只是“数据”而不可能变成“指令”二是同一个SQL模板只需要编译一次后续重复执行时直接复用执行计划省掉了重复解析的开销。1.3 用一张表看清Statement和PreparedStatement的差异对比维度StatementPreparedStatementSQL编译每次执行都完整解析、编译首次编译后缓存执行计划重复执行直接复用参数传递拼接进SQL文本靠转义自求多福通过占位符传参驱动自动处理类型转换SQL注入风险高取决于开发者是否做了严格的过滤、转义低参数不会改变SQL语义批量执行需逐条发送SQL文本网络开销大支持预编译批处理可显著减少通信与解析成本可读性与维护性长字符串拼接读起来费劲模板与参数分离代码结构清晰类型安全全部变成字符串强制转换容易出错驱动会按参数类型做相应处理减少转型问题注意PreparedStatement也不是绝对保险比如错误地使用字符串拼接来构造SQL模板本身或者在某些驱动版本中参数类型与数据库列类型不匹配导致隐式转换依然可能带来意外。但相比Statement它把风险降到了很低的量级。2. 说透Connection.createStatement背后的设计逻辑2.1 拿到Statement之前连接层做了什么用JDBC执行一条SQL第一步永远是取得Connection。而Connection.createStatement()这个调用很多人没有仔细想过它的开销。它并不是简单地“取一个现成的对象”而是经过了一系列步骤首先是连接池获取连接。如果用的是HikariCP这类池化组件这一步大多数时候是复用已有连接开销很低。但如果没有连接池每次new一个连接都要经过TCP握手、认证、会话初始化等流程这个成本可能达到几十甚至上百毫秒比执行一条简单SQL还贵。然后是Driver层的处理。调用createStatement时驱动会返回一个Statement对象但它本质上是和这条连接绑定的。驱动内部可能还会懒加载一些元数据、设置会话变量、准备结果集游标等。不同驱动实现各有差异MySQL Connector/J和PostgreSQL JDBC Driver的处理就不完全一样但共同点是这个环节有开销而且连接的状态会影响创建Statement的成本。再说说自动提交。默认情况下JDBC连接是自动提交模式autoCommit true也就是说你每执行一条SQL数据库都会立即提交事务。这个机制在单条SQL场景下很简单但在一个业务方法里执行多条UPDATE时就会产生多次事务提交每一次提交都要刷写日志、释放锁性能损耗非常明显。所以早年的实践往往都会在执行多条语句之前先调用connection.setAutoCommit(false)最后统一commit。2.2 Statement的三种基础操作拿到Statement之后最常用的三个方法就是executeQuery、executeUpdate和execute。executeQuery用于执行SELECT返回的是ResultSet这个对象承载查询结果。注意ResultSet并不是一次性把所有数据拉到内存而是一般通过流式方式从数据库逐行读取不同驱动实现细节不同。这意味着如果查询返回了海量数据但你没有及时关闭ResultSet连接和数据库端的游标资源就会被长期占用。executeUpdate用于INSERT、UPDATE、DELETE等DML操作返回的是受影响的行数。很多人忽略的细节是某些数据库甚至某些版本的驱动对executeUpdate返回的“行数”语义有歧义尤其是在批量操作时返回的是每批的行数还是累计行数需要实测确认。execute是一个通用方法SELECT和DML都能执行。如果SQL是SELECT返回值为true需要通过getResultSet拿结果集如果是DML返回值为false需要靠getUpdateCount获取受影响行数。这个方法的定位在于SQL类型不确定的场景比如动态生成的工具类。还有一个容易被忽略的点——所有Statement对象在数据库层面最终都会对应一个游标或执行句柄。如果创建了Statement但对结果集只处理了一半就丢到一边既没有关闭Statement也没有关闭ResultSet长此以往连接池里的连接会被这些“半死状态”占满新请求拿不到连接业务就挂了。2.3 ResultSet游标和数据类型转换ResultSet的游标机制恰恰解释了为什么那句“数据集从数据库取到本地”的说法不准确。默认情况下Type为TYPE_FORWARD_ONLYConcurrency为CONCUR_READ_ONLY也就是只能向前移动、只读。这已经覆盖了绝大多数业务场景。但在某些特殊场景下比如你需要在一个事务里先查询再更新某一行很多人会下意识想用ResultSet去updateRow。这时就要确认驱动的ResultSet到底是否支持可滚动、可更新。MySQL的驱动默认是不支持的强制使用很容易抛异常。更合理的做法是查出主键后另起一条UPDATE语句而不是试图在ResultSet上直接改。数据类型转换也是坑。数据库里的DECIMAL、BIGINT、DATETIME通过getString获取时驱动会做转换但有些转换会导致精度损失尤其是BIGINT超过Long.MAX_VALUE时或者DATETIME在不同时区下的显示值不一样。通常我建议按列的真实类型去取数据能取Long就不取String能用LocalDateTime就不硬拼字符串。3. 为什么生产环境几乎见不到裸Statement3.1 预编译的执行路径PreparedStatement的好处官网文档和各类教程都说了很多但我想从执行路径的角度讲一下。在MySQL Connector/J中PreparedStatement的执行过程大概是这样的客户端把SQL模板和参数通过二进制协议发送到服务端服务端先解析SQL并生成执行计划将执行计划缓存起来之后如果相同的SQL模板再次到达就可以直接使用缓存的执行计划而不用再解析一遍。但这里有一个隐藏关键点并不是所有“看起来一样”的SQL都能命中缓存。SQL文本必须完全一致包括大小写、空格、换行。比如SELECT * FROM t_user WHERE id ?和SELECT * FROM t_user WHERE id? -- 注意少了空格或者是全大写在大部分数据库里被认为是不同的SQL所以缓存就失效了。很多人喜欢用工具自动格式化SQL在开发环境看着舒服但如果在代码里通过模板引擎拼接SQL格式不统一就会导致预编译形同虚设。更隐蔽的问题是MySQL默认对PreparedStatement的预处理是“客户端模拟”的。MySQL Connector/J里面有一个参数useServerPrepStmts默认是false。也就是说如果不显式开启PreparedStatement的占位符是在客户端完成的SQL并没有真正发送到服务端做预编译。这种情况下防注入的能力依然有效但性能收益会打折扣。生产环境中如果希望真正利用服务端预编译通常需要jdbc:mysql://localhost:3306/test?useServerPrepStmtstruecachePrepStmtstrue开启cachePrepStmts后驱动会在客户端缓存PreparedStatement句柄避免重复请求服务端创建预编译语句。这个参数的影响在我实测的项目里语句重复执行上百次时整体耗时能降低20%以上尤其是复杂SQL。但也不是越大越好假如每个业务方法都构造自己独有的SQL文本缓存里会积累大量无用的预编译语句反而增加内存压力。3.2 性能差异的定量感受很多同学问用Statement重复插入1000条记录和用PreparedStatement批量插入差距到底有多大我做过一个简单的对比测试本机数据库插入1000条数据每条数据10个字段左右。用Statement逐条拼接执行耗时大约800毫秒到1秒用PreparedStatement逐条执行耗时大约600到700毫秒用PreparedStatement的批量模式addBatch executeBatch耗时能压缩到100毫秒左右。为什么批量模式这么快因为减少了网络往返次数。逐条插入时每条数据都要发送一个完整的请求1000条就是1000次往返批量模式可以把1000条数据的参数一次性打包发送当然驱动内部会按阈值分批网络通信次数大幅减少。还有一个原因是每条SQL的编译工作只做一次后续执行计划复用。这个测试说明PreparedStatement并不只是安全性的选择更是性能和资源利用的选择。尤其是你的业务中频繁执行结构相同、参数不同的SQL时预编译的收益相当可观。3.3 用PreparedStatement的正确姿势用法上和我见过很多半路出家的代码对比有几个容易被忽略的细节占位符是1-based——?的下标从1开始不是0。这个错误藏在代码里非常隐蔽因为大多数时候你只在JDBC代码里和下标打交道一旦列多、条件长、动态SQL复杂越界和错位几乎是必然。我的建议是动态条件多时先把条件和参数分别存入List再按顺序绑定。参数类型要用setObject还是setString—— 新手习惯setString(1, value)但对于日期、数字、Boolean这种字段setString会让数据库做一次隐式类型转换可能无法命中索引。正确的做法是按Java类型选择setInt、setLong、setTimestamp、setBigDecimal等方法。如果字段类型确实不确定可以用setObject驱动会按照Java对象的类型去映射。不要在一次执行中反复设置同一参数—— 很多人会在循环里重新调用setString其实这是允许的但要注意有些驱动会检查参数是否变更频繁变更本身也会增加额外的状态同步开销。更合理的做法是循环内部尽量只修改必要的参数或者直接复用已经绑定好的参数。用完就关别靠GC—— Statement、ResultSet、Connection这三个对象的关闭顺序也很讲究。最标准的做法是在try-with-resources中逆序声明先声明Connection再声明PreparedStatement最后声明ResultSet。这样当try块结束时关闭顺序正好是ResultSet → Statement → Connection不会出现“连接忘了关”的问题。4. 实操用PreparedStatement完成一整套数据库操作4.1 基础增删改查的代码骨架直接给出一套常见的基础代码注释里写清楚每一步的含义public ListUserDO listUsers(Date startTime, Date endTime) { String sql SELECT id, name, created_at FROM t_user WHERE created_at BETWEEN ? AND ?; ListUserDO users new ArrayList(); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { // 占位符从1开始第一个?对应startTime第二个?对应endTime ps.setTimestamp(1, new Timestamp(startTime.getTime())); ps.setTimestamp(2, new Timestamp(endTime.getTime())); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { UserDO user new UserDO(); user.setId(rs.getLong(id)); user.setName(rs.getString(name)); user.setCreatedAt(rs.getTimestamp(created_at).toLocalDateTime()); users.add(user); } } } catch (SQLException e) { // 生产环境应替换为更精细的日志和异常转换 log.error(query users failed, sql{}, startTime{}, endTime{}, sql, startTime, endTime, e); throw new RuntimeException(query user failed, e); } return users; }这段代码核心的几个点占位符和set方法一一对应try-with-resources保证了连接、语句、结果集都被正确关闭使用setTimestamp来绑定时间字段避免字符串拼接引发格式问题。看似简单但在真实项目中这些细节决定了代码是能稳健运行还是三天两头出bug。4.2 批量插入的正确写法批量插入是最能体现PreparedStatement价值的场景。在订单、日志、行为流水等数据量较大的写入场景中批量插入几乎是必修课。一个标准的写法如下public void batchInsertOrders(ListOrderDO orders) { String sql INSERT INTO t_order (order_no, user_id, amount, status, created_at) VALUES (?, ?, ?, ?, ?); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { // 关闭自动提交便于统一事务管理 conn.setAutoCommit(false); int batchSize 0; for (OrderDO order : orders) { ps.setString(1, order.getOrderNo()); ps.setLong(2, order.getUserId()); ps.setBigDecimal(3, order.getAmount()); ps.setString(4, order.getStatus()); ps.setTimestamp(5, Timestamp.valueOf(order.getCreatedAt())); ps.addBatch(); batchSize; // 每500条提交一次避免单次批处理过大导致内存占用过高 if (batchSize % 500 0) { ps.executeBatch(); } } // 提交剩余不足500条的批次 ps.executeBatch(); conn.commit(); } catch (SQLException e) { // 出错时回滚避免部分数据残留 log.error(batch insert orders failed, e); try (Connection conn dataSource.getConnection()) { conn.rollback(); } catch (SQLException ex) { log.error(rollback failed, ex); } throw new RuntimeException(batch insert orders failed, e); } }这里有几个心得。分批提交的阈值我一般设置为200到500条。太大的话单次executeBatch会占用大量内存保存参数数据太小的话又没法有效减少网络往返。另一个坑是如果某一条数据在批处理中执行失败数据库的行为取决于QO和驱动实现有的会直接中断整个批次有的会继续执行后面的还有的会抛出BatchUpdateException并携带成功数。所以捕获异常时最好把BatchUpdateException的getUpdateCounts打出来看看明确哪些成功、哪些失败。4.3 获取自增主键插入一条记录后经常需要立即拿到自增ID用Statement.RETURN_GENERATED_KEYS的写法非常方便。PreparedStatement同样支持String sql INSERT INTO t_biz (biz_name) VALUES (?); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, bizName); ps.executeUpdate(); try (ResultSet rs ps.getGeneratedKeys()) { if (rs.next()) { Long id rs.getLong(1); return id; } } }但要注意getGeneratedKeys的有效性和数据库/驱动强相关。MySQL是支持的PostgreSQL也能用但某些老版本的驱动或某些中间件可能拿到空结果。如果项目本身是双数据库兼容我建议用规范的SQL查询方式回查一遍主键而不是完全依赖这个功能。另外如果插入语句里指定了主键值那getGeneratedKeys大概率返回空这是常见误解。4.4 动态查询条件组合动态SQL在业务系统中太常见了但很多人还是抱着“拼接字符串”的思维去写。PreparedStatement的动态SQL要稍微绕一下但思路很明确先用List收集条件片段和参数再一次性生成SQL。public ListUserDO search(String name, Integer minAge, Integer maxAge) { StringBuilder sql new StringBuilder(SELECT id, name, age FROM t_user WHERE 1 1); ListObject params new ArrayList(); if (StringUtils.hasText(name)) { sql.append( AND name LIKE ?); params.add(% name %); } if (minAge ! null) { sql.append( AND age ?); params.add(minAge); } if (maxAge ! null) { sql.append( AND age ?); params.add(maxAge); } try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql.toString())) { for (int i 0; i params.size(); i) { ps.setObject(i 1, params.get(i)); } try (ResultSet rs ps.executeQuery()) { // 处理结果... } } }这里的核心是“参数和条件同步收集”这样就避免了在拼接SQL时还要重新数占位符的尴尬。条件一多这种写法尤其省心。注意LIKE语句中%和_是放在参数里拼接的不能在SQL模板里直接写否则占位符会被通配符干扰查询结果和预期完全不一样。5. 常见坑与排查实录5.1 连接泄漏——我见过最普遍的事故连接泄漏是所有使用Connection的程序员的噩梦它的表现不是“立刻报错”而是“运行几天后突然大量超时”。我见到过的典型场景某同学在方法里获取了Connection但忘记在finally里关闭因为平时流量小看不出问题一旦流量上来连接池的可用连接被占满新请求全部排队最终触发了雪崩效应。排查方法很简单开启连接池的泄漏检测。HikariCP可以配置leakDetectionThreshold比如设为10000毫秒连接从池中借出超过这个时间没有归还日志里就会打印一段带堆栈的警告那一段堆栈能直接定位到是哪一行代码借了连接没还。这个方法救过我好几次强烈建议线上开启代价是微乎其微的性能开销。另一个防止连接泄漏的实践是避免在try块里手动close而是使用try-with-resources。但要说清楚try-with-resources只能保证“声明在try括号里的资源”被关闭如果你在方法内部先获取了Connection然后又传给另一个方法去执行SQL关闭的责任就要被清晰定义否则很容易出现“我关了你还在用”的异常或者反过来“你没关你也不管”的泄漏。5.2 where in 参数占位符失效很多人在SQL里写WHERE id IN (?)然后试图用setString把一组ID传进去结果发现只匹配到一条数据甚至报错。原因很简单JDBC的占位符是“一个占位符对应一个值”并不是“一个占位符对应一个列表”。我一般推荐两种方案。第一种是动态生成占位符串ListLong ids Arrays.asList(1L, 2L, 3L); String placeholders ids.stream().map(id - ?).collect(Collectors.joining(,)); String sql SELECT * FROM t_user WHERE id IN ( placeholders );这种方式直白且兼容性好。注意IN子句的列表不宜过长否则不仅SQL文本变大数据库执行计划也可能退化。超过1000个ID时我一般会分批查询或者改用临时表关联。第二种方案是对接一些高级特性比如PostgreSQL的数组类型、MySQL的JSON_CONTAINS但前提是你的数据库版本和驱动都支持而且不能为了用特性而牺牲可移植性。5.3 大结果集吃内存ResultSet默认是一次性把数据拉回客户端吗其实不一定。MySQL驱动在处理大结果集时有useCursorFetch参数。默认情况下MySQL是边读边取的但如果你执行了一条返回十万行的查询又不想全部加载到内存可以考虑设置statement.setFetchSize(Integer.MIN_VALUE)这会启用流式读取逐行从服务端取数代价是读取期间不能执行其他语句某些版本lock了连接。很多做报表导出、大批量数据同步的同学在这块踩坑最多。明明查了几万行数据就把内存打满其实就是没有显式设置fetchSize驱动可能是把结果一次性拉到了客户端。解决方式要先确认驱动行为再去设fetchSize不要想当然。5.4 事务超时与自动提交误区事务和Statement的关系很多人理解是“事务就是多条SQL放在一起”。但一个容易忽视的点是在JDBC里事务边界由Connection控制而不是由Statement控制。如果在一个方法里打开事务先执行了INSERT中途抛了异常但你只关闭了Statement没有回滚这个事务可能一直挂着占着数据库连接和锁资源。更糟糕的误操作是把setAutoCommit(false)和commit写进了循环里。每调一次commit事务就结束了后续SQL自动开启新事务。如果业务上需要“全部成功或全部失败”这种写法是灾难。我见过一个定时任务就是因为循环里commit导致前面一批数据处理成功、后面失败时无法回滚最终产生了数据不一致。建议把事务管理放到独立的层比如Spring的Transactional避免自己在业务代码里散落地调用setAutoCommit和commit这样不仅清晰也容易被框架的统一机制兜底。5.5 预编译缓存被撑爆服务端预编译虽然好但如果你在SQL模板里拼接了很多不同的字符串值比如把表名、字段名、排序字段也拼进去那缓存里会有成千上万个不同的SQL模板内存和解析开销都上来了。这种情况下你不仅没享受到预编译的复用收益反而比Statement更糟。我的一个习惯是表名、字段名、排序字段这些“SQL结构”部分最好通过白名单的方式去映射不要直接用外部参数拼接。比如前端传一个orderBy字段代码里就做一个Map映射只允许白名单里的值进入SQL其他值一律用默认排序。这样既安全又保证了SQL模板的数量可控。5.6 一个容易被忽略的参数绑定顺序问题之前说过占位符从1开始这里再补充一个实战细节。在动态SQL中如果你先检查A条件再检查B条件那么参数绑定的顺序也必须严格按照条件出现的顺序来。代码里第一次写时A条件在前面B条件在后面后来有人调整了条件的先后顺序但忘了调整参数List的添加顺序结果就是查询结果完全错乱而且不会报错。这种bug极其隐蔽排查时最好的办法是在日志里把最终SQL和绑定的参数一起打出来肉眼对一遍。6. 一些长期实践下来的心得体会6.1 建议的代码组织方式围绕Statement和PreparedStatement我建议项目里往这几个方向去建设统一SQL管理SQL不要散落在业务代码里尽量收拢到DAO层的常量或XML中方便审计和优化。统一异常处理JDBC抛出的SQLException信息很笼统建议包装成带SQL、参数、错误码的领域异常方便定位。统一参数绑定如果项目里没有用ORM框架可以封装一个简单的JdbcHelper内部统一管理占位符绑定和资源关闭避免每个方法都重复写try-with-resources模板。适当引入ORM当项目复杂到一定程度纯手写JDBC的维护成本会非常高这时选用成熟的ORM框架比如MyBatis或Spring JdbcTemplate并不丢人但底层原理仍然是今天讲到的这些内容。6.2 需要避开的几个“反模式”用Statement拼接用户输入除了教学Demo我建议生产代码里完全杜绝。为了图省事统一setString导致索引失效。该setInt就setInt该setTimestamp就setTimestamp。在一个方法里创建多个Statement对象。比如先查一次再插入一次再查一次你完全可以用同一个Statement执行多条SQL当然不同预处理语句除外没必要每条SQL都创建新对象白白增加驱动和数据库的开销。企图修改ResultSet里的值来更新数据库。这个在多数驱动里是不支持的即便支持也容易引发并发问题不是一个好的实践。忽视数据库和驱动的版本差异。同一个功能在不同版本的MySQL驱动上行为可能不同比如getGeneratedKeys、服务端预编译、大结果集流式读取升级驱动后要重点回归。6.3 写在最后的一点体会我个人在实际项目里的感受是Connection.createStatement这行代码本身没有任何问题它不是洪水猛兽但它只是一个起点。真正让你少加班的是你对Statement机制的理解深度——你清楚参数如何绑定、执行计划如何缓存、连接和事务的边界在哪里你才能在遇到诡异的线上故障时迅速判断问题是出在SQL本身、连接状态、还是驱动行为上。这些年修复过的很多看似神秘的数据库问题追根究底大部分都绕不开今天聊的这几个细节。希望这篇总结能帮你少走一些弯路也欢迎你在自己的项目里实测一下批量模式的性能提升实践出来的结论比任何文档都可靠。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
