说实话，写JDBC这个话题，我心里有点复杂。这玩意儿是Java世界里最老的那批技术之一，二十多年了，新人嫌它繁琐，老手又离不开它。但恰恰是这份“又爱又恨”，让JDBC成了检验一个Java程序员底子的试金石。你框架玩得再花，MyBatis、Hibernate用得再溜，一旦遇到诡异的连接超时、慢查询、或者莫名其妙的死锁，翻来翻去，还是得回到JDBC这层来解决问题。所以今天这篇东西，我不打算给你念API文档，那些玩意儿官网都有，我主要想聊聊实战里那些坑，以及从能跑，到跑得快的那些门道。
先说说最基础的，很多人第一步就栽在连接管理上。新手写代码，喜欢在方法里直接，用完了也不关，或者干脆等垃圾回收。这在Demo里没毛病，但放到生产环境，数据库连接数几分钟就能被耗尽，紧接着就是一堆的异常刷屏。正确做法是得用连接池，HikariCP、Druid都行。你可能会问，这跟JDBC有啥关系？关系大了去了，连接池底层拿到的还是JDBC的Connection，只是帮你管好了生命周期。我见过一个老项目，就是因为图省事没用连接池，每次请求都新建物理连接，结果数据库CPU常年飙到80%，换了个连接池配置，直接降到15%。你看，性能问题有时候根本不在于SQL写得多烂，而是你压根没给数据库喘气的机会。
说到SQL这块，PreparedStatement绝对是必须养成的肌肉记忆。别跟我说你用Statement拼接字符串挺顺手的，SQL注入先不提，单说性能，PreparedStatement预编译一次，后面重复执行就只传参数，数据库不用每次重新解析SQL语句，这个开销省下来非常可观。我有个朋友，他们团队有个老哥特别喜欢用字符串拼接查数据，结果上线第二天就被安全团队找上门了，因为用户输入框里输了个，直接把整个表给脱了。这真不是段子，是血泪教训。而且PreparedStatement还有个好处，它能把特殊字符正确转义，你处理用户输入的时候，至少不用自己造轮子去转义引号了，少踩不少坑。
再往下走，就到了ResultSet的处理。很多初学者喜欢用循环，然后一个个、，这没问题，但你要知道，默认情况下ResultSet是把你查出来的所有行一次性加载到内存里的。数据量小没事，你要是查个几十万行，内存直接爆给你看。这时候得用流式读取，也就是在Statement上设置，配合MySQL的，才能让数据库一行一行吐给你，你处理完一行丢一行，内存压力瞬间就下来了。不过这块得注意，流式读取的时候，连接是被占用的，你不能同时再开别的查询，不然会报错。所以用完赶紧关，别磨叽。
事务这块，是JDBC里最容易出大问题的地方。很多人以为只要写了，然后就万事大吉了，但隔离级别你设了吗？默认的隔离级别在MySQL里是，在Oracle里是，这俩处理并发场景的机制完全不一样。你要是没搞清楚自己用的什么数据库，就敢乱设隔离级别，轻则读到脏数据，重则直接死锁。我建议新手先老老实实把用起来，虽然性能上不是最优，但至少不会出现那种让你半夜爬起来查数据的灵异问题。另外，事务边界一定要短，别在事务里去做远程调用或者复杂的业务计算，你抱着数据库连接不放，别人都得排队等你。
批处理这块，很多老手都容易忽略。你想想，要往一张表里插入一万条数据，一条一条executeUpdate，光网络往返就得一万次，每次都得等数据库确认，这效率能高到哪儿去？正确姿势是用和，攒够一批（比如500条）再一次性提交，配合PreparedStatement的预编译，插入性能能提升一个数量级。我自己做过个压测，单条插入一万条大概要四十多秒，改成批处理之后，不到两秒就跑完了。不过批处理有个坑，就是中途失败了不好回滚，你得自己掌控批次大小，还得考虑幂等性，不然重复执行会插出重复数据来。
性能调优的更进阶一层，就是得学会看执行计划。JDBC本身不提供这个能力，但你可以在SQL前面加关键字，或者通过的来限制返回行数，提前把那些全表扫描的慢SQL揪出来。我见过最夸张的案例，一个查询就查个订单状态，结果没建索引，扫了八百万行，耗时三秒多，加了个联合索引之后，瞬间变成三毫秒。你可能会说，这跟JDBC有什么关系？关系太有了，因为JDBC的、这些参数，就是给你调优用的。比如，超过五秒直接抛异常，防止慢SQL拖垮整个服务，这种保护机制在线上环境里简直是救命稻草。
聊聊连接泄漏的问题，这可能是JDBC实战里最阴间的坑。代码里写了，finally里也关了ResultSet、Statement、Connection，但线上跑着跑着，连接数还是涨上去了。为啥？因为很多框架的代理对象，你关的只是代理，真正的物理连接还攥在池子里。更阴间的是，有些老代码在catch块里只打印了个日志就return了，连接根本来不及关。要排查这种问题，光靠肉眼盯代码是不行的，得在连接池里配置，比如设为30秒，一旦连接借出去超过这个时间没归还，就打印出堆栈，你一看就知道是哪个方法借了没还。这招我每次给客户排查问题必用，十次里有八次能直接定位到凶手。
你看，从最基础的连接管理，到PreparedStatement的防注入，再到流式读取、事务边界、批处理，到执行计划和泄漏检测，每一个环节都藏着能让你性能翻倍或者翻车的细节。JDBC这东西，你说它老，它确实老，但正是因为它老，反而沉淀了最扎实的数据库交互原则。你把这些原则吃透了，再去用那些所谓的新技术，会发现本质都是一回事。框架只是帮你封装了复杂度，但如果你连JDBC这层都搞不定，框架出了问题，你连排查的方向都没有。所以别嫌它啰嗦，多写几个原生JDBC的Demo，把每一步发生了什么搞清楚，这比背十篇框架配置都管用。
