写代码这么多年，要说哪件事能让新手瞬间眉头紧锁，Java连数据库绝对排得上号。配置文件写了一大堆，驱动加载报错，连接超时，SQL异常……每一个坑都能让人抓狂半天。但话说回来，这又是Java开发绕不过去的坎，从学生作业到企业级系统，哪哪都离不开它。今天这篇文章，我就把Java连接数据库这条路从头到尾捋一遍，从最基础的JDBC原理，到连接池、ORM框架，再到实战中那些容易踩的坑，一步不落全给你讲清楚。
先说最原始的JDBC，它就像数据库连接的“母语”。很多人一上来就学MyBatis、Hibernate，结果底层原理一问三不知，出了问题只能干瞪眼。其实JDBC的核心就六个步骤：加载驱动、获取连接、创建Statement、执行SQL、处理结果集、关闭资源。听起来简单，但每一步都有讲究。比如加载驱动，早期要写，现在MySQL 8以上的驱动类名改成了，而且还多了时区参数。这些细节，不踩一次坑根本记不住。
接下来是获取连接，这一步最让人头疼。，URL的格式是。别小看这几个参数，是关掉SSL警告，是防止中文乱码。我记得刚工作时，就因为没加编码参数，线上数据全是问号，被运维大哥骂了一下午。所以写URL的时候，参数宁可多写也别少写，特别是字符集和时区，这俩是必填项。
但JDBC有个致命问题——每次操作都要手动开关连接，性能差得离谱。一个简单的查询，连接建立可能要花几十毫秒，而SQL执行本身才几毫秒。所以后来的C3P0、Druid、HikariCP这些连接池就派上了用场。连接池的原理特别直白：先创建一批连接放在池子里，用的时候借，用完还，省去了反复建立连接的开销。现在Spring Boot默认用的是HikariCP，号称史上最快连接池，配置也简单，就几个核心参数：是最大连接数，是最小空闲连接数，是获取连接的超时时间。生产环境里，这两个数得根据并发量来调，调大了浪费资源，调小了请求排队。
连接池之外，还有一层更高级的封装——ORM框架。MyBatis和Hibernate算是国内用得最多的两个。MyBatis的灵活之处在于SQL完全由你掌控，适合复杂查询和报表类需求；Hibernate则是全自动映射，写个对象就能自动建表、自动CRUD，适合业务逻辑清晰、表结构稳定的场景。但不管用哪个，底层还是走JDBC那一套，只是把样板代码封装起来了。比如MyBatis的，本质上还是拿着JDBC的Connection在执行SQL。
说到实战，必须聊聊那些年我们踩过的坑。第一个坑是连接泄漏。很多人写代码，开了不关，或者关了但异常路径没走到关闭代码，结果连接池被耗尽，应用直接假死。解决办法是用语法，Java 7以后就能自动关闭实现了接口的资源，省心又安全。第二个坑是SQL注入。别用字符串拼接SQL，一定要用的占位符，既防注入又提升性能，因为预编译的SQL可以重复利用执行计划。
还有一个坑特别隐蔽——事务边界。很多人以为在方法上加了注解就万事大吉，但如果你在同一个类里调用另一个带事务注解的方法，Spring的代理机制会失效，事务压根不生效。这种问题排查起来特别费劲，因为代码逻辑完全没问题，但数据就是不对。所以要么把事务方法放到独立的Service类里，要么用手动管理。
再来说说数据源配置。现在主流的是用Spring Boot的，配置一个就够了。但有个细节很多人忽略——连接池的检测语句。MySQL默认的检测SQL是，但这个语句不会真正访问数据，有时候连接虽然断了但检测不出来。建议换成，或者用连接池推荐的检测SQL，比如HikariCP的参数。另外，生产环境一定记得配置和，防止数据库主动断开空闲连接后，连接池还在傻傻地复用坏连接。
说说性能优化。很多人一遇到慢查询就想着加索引，但有时候瓶颈根本不在SQL，而在连接本身。比如连接池太小，大量请求在排队等连接，这时候加索引没用，得调大。还有网络延迟，如果数据库和应用不在同一机房，每次查询都要跨网络，那性能再怎么优化也白搭。所以架构设计上，数据库最好和应用部署在同一内网，必要时用读写分离，读操作走从库，写操作走主库，分摊压力。
走到这里，Java连数据库这条路算是摸清了。从JDBC的六个步骤，到连接池的性能调优，再到ORM框架的取舍，还有实战中的那些坑，每一步都是前人踩出来的经验。说实话，这些知识不是看一遍就能融会贯通的，得自己动手写几个项目，把连接泄漏、并发超时、事务回滚这些场景都亲身体验一遍，才能真正吃透。但有一点是肯定的——无论框架怎么变，底层原理永远是那套JDBC规范。掌握了它，不管以后冒出什么新工具，你都能一眼看穿本质。
