刚入行的 Java 程序员，十有八九都被数据库连接折磨过。写代码时明明感觉逻辑都对，结果一运行就报 “ClassNotFoundException” 或 “No suitable driver”，那种抓耳挠腮的滋味，估计不少人还记得。其实 JDBC（Java Database Connectivity）说白了就是 Java 和数据库之间的一座桥，它定义了一套标准接口，让你不用管底层是 MySQL 还是 Oracle，只要调同样的方法就能连上数据库。但这座桥怎么搭、怎么走，里面藏着不少细节，今天咱们就来聊聊这事儿。
先说说最基础的步骤。要用 JDBC 连接数据库，得先搞到对应的数据库驱动。比如连 MySQL，就得下载 mysql-connector-java 这个 jar 包，然后把它加到项目的 classpath 里。这一步卡住过无数新手，有人忘了加，有人加错了版本，还有人直接复制粘贴网上的代码，结果驱动类名写错了。MySQL 8.x 的驱动类名是 “com.mysql.cj.jdbc.Driver”，而 5.x 版本是 “com.mysql.jdbc.Driver”，这两个就差一个 “cj”，但搞错了就连不上。注册驱动之后，还得拼一个连接字符串，里面要写数据库的 IP、端口、库名、用户名和密码，比如 “jdbc:mysql://localhost:3306/test?useSSL=false&serverTimezone=UTC”。这串东西看起来像乱码，但每个参数都有讲究，例如 useSSL=false 是关掉 SSL 加密，省得本地开发时出警告；serverTimezone=UTC 是设时区，不然时间字段可能跳来跳去。
拿到 Connection 对象之后，下一步就是发 SQL 了。JDBC 里最常用的两个接口是 Statement 和 PreparedStatement。很多人图省事，直接用 Statement 拼 SQL 字符串，例如 “SELECT FROM users WHERE name = '” + input + “'”。这种写法在练手项目里还能跑，但一上线就原形毕露——只要用户输入个 “' OR '1'='1'”，你的 SQL 就变成了 “SELECT FROM users WHERE name = '' OR '1'='1'”，直接把所有用户数据全捞出来。这就是经典的 SQL 注入攻击，轻则数据泄露，重则整个库被删光。PreparedStatement 正是为了解决这个问题，它用占位符 “?” 代替变量，然后通过 setString、setInt 等方法把参数传进去，驱动会自动把特殊字符转义。比如 “SELECT * FROM users WHERE name = ?”，即使传入 “' OR '1'='1'”，也只会被当作普通字符串，不会破坏 SQL 语法。而且 PreparedStatement 还有预编译的优势，同样的 SQL 执行多次时，性能比 Statement 高不少。
拿到 ResultSet 之后，很多人以为就万事大吉了，其实坑才刚开始。ResultSet 默认是单向游标，只能从前往后遍历，数据是一行行从数据库拉回来的。如果你查询了十万条数据，用 next() 方法一条条读，内存里并不会一次性装下，而是按需加载。但有些程序员图省事，直接把 ResultSet 转成 List 塞进内存，结果数据量一大，服务器就会 OOM（Out of Memory）。更隐蔽的问题是，ResultSet 依赖数据库连接，如果忘了关闭，或者关闭顺序搞错，连接池里的连接会被一直占用，导致后续请求排队。正确的做法是：先关 ResultSet，再关 Statement，最后关 Connection。或者直接使用 try‑with‑resources 语法，Java 7 之后可以自动在代码块结束时关闭资源，省得写一堆 finally 块。例如：三个资源一口气搞定，简洁又安全。
事务控制这块，很多人要么完全不用，要么滥用。默认情况下，JDBC 是自动提交的，每条 SQL 执行完就立刻写入数据库。如果要进行批量操作，比如银行转账，先扣 A 的钱再加到 B 的账户，这两步必须在同一个事务里完成，否则中间断电了，A 的钱没了 B 的钱也没加上，用户会骂娘。这时就要调 ，等所有操作执行完再调 。如果中间出错，就调 把数据回滚到操作前的状态。但事务不是万能的，别给每个查询都加事务，那样会拖慢性能，还容易造成死锁。另外，事务隔离级别也要注意，MySQL 默认是可重复读（REPEATABLE READ），在某些场景下会读取到快照版本。如果在事务里查询同一条记录两次，结果可能不一样，需要根据业务需求调整为读已提交（READ COMMITTED）或串行化（SERIALIZABLE）。
连接池算是 JDBC 的进阶玩法。早期程序员每次请求都 一个 Connection，用完再 。在并发量低的系统还能凑合，但一旦访问量上来，频繁创建和销毁连接的开销会把数据库拖垮。连接池的思路很简单：提前创建一批连接放在池子里，谁用谁取，用完归还，避免重复创建。市面上常见的连接池有 HikariCP、Druid、C3P0 等，其中 HikariCP 性能最好，Spring Boot 默认就用它。配置连接池时，有几个关键参数：最大连接数（maxPoolSize）设太大，数据库扛不住；设太小，请求会排队超时。一般建议根据业务峰值来估算，例如系统每秒处理 500 个请求，每个请求耗时 100 毫秒，至少需要 50 个连接。还要注意连接泄漏，即代码里忘了关连接，导致池子里的连接被慢慢耗尽。Druid 提供监控页面，能实时看到活跃连接数和泄漏检测，对排查问题很有帮助。
说点实战中容易踩的坑。第一，时区问题。很多程序员在本地开发时，数据库和系统时区一致，一切正常。但部署到云服务器上，服务器时区是 UTC，数据库时区是 Asia/Shanghai，查询出来的时间字段会差 8 小时。解决办法是在连接字符串里显式指定 ，或者统一把数据库和服务器时区改成 UTC，应用层再做转换。第二，字符编码。如果数据库使用 UTF‑8，但 JDBC 连接没指定 ，中文可能会变成问号。第三，大字段处理。存图片或长文本时使用 Blob 或 Clob 类型，读取后要记得关闭流，否则会泄漏内存。第四，批量插入性能。如果要插入一万条数据，别一条条插入，而是使用 和 ，配合 参数，MySQL 会把这些 SQL 合并成一条大的 INSERT，性能提升数十倍。第五，连接超时。默认情况下，JDBC 不会主动检测连接是否有效，如果连接池里的连接被数据库侧断开（比如数据库重启或防火墙超时），应用仍会使用这个“死连接”发 SQL，导致报错。解决办法是配置连接池的验证查询（validationQuery），如 MySQL 用 ，每次拿连接前先检测一下是否还活着。
说到底，JDBC 虽然是个老技术，但它把数据库操作的底层细节封装得还不错。只要理解了连接的创建、SQL 的执行、结果的处理和资源的释放这四步，再配合事务和连接池，基本就能应对大多数场景。别把 JDBC 想得太玄乎，它就是个工具，用多了自然熟练。但千万别因为它简单就轻视它，那些线上爆过的坑，十有八九都是因为连接没关、SQL 注入、事务没处理好这些“小问题”。当你亲手排查过一次因为连接泄漏导致的服务雪崩，或者因为 SQL 注入导致数据被删的惨案，你就会明白，基础的东西往往最要命。下次写代码时，多花一分钟检查资源是否关闭，多问一句 SQL 是否安全，比什么都强。
