MySQL JDBC连接数据库全指南：驱动配置、连接池与异常排查

MySQL JDBC连接数据库，这个事看起来简单，但真正动手做的时候，驱动版本、URL格式、时区配置、连接池参数，任何一个地方出问题都能卡你半天。网上教程大多只给一段代码让你复制，却没人告诉你为什么这么写、报错了怎么排查。这篇文章我把从环境准备到代码编写再到问题排查的完整链路捋一遍，全程基于实际踩坑经验，希望能帮你一次跑通。

这个教程适合Java初学者、刚转后端开发的工程师，以及需要接手老项目维护的朋友。你不需要有深厚的数据库功底，只要装好了MySQL和JDK，跟着步骤走就能跑起来。

1. 连接MySQL前的准备工作：驱动版本与环境配置

1.1 为什么版本选择是第一道坎

先说一个最容易踩的坑：驱动版本和MySQL服务器版本不匹配。

很多人直接去Maven仓库搜"mysql-connector-java"，看到最新版就拖进来，结果连MySQL 5.7报错，或者连MySQL 8.0时报Public Key Retrieval is not allowed。实际上，从MySQL Connector/J 8.0开始，驱动类的包名从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，URL中也需要显式指定时区参数。

我的建议是：

• 连接MySQL 5.7及以下版本：用mysql-connector-java 5.1.49，驱动类写com.mysql.jdbc.Driver。
• 连接MySQL 8.0及以上版本：必须用mysql-connector-j 8.0.x（注意新版Maven坐标变了），驱动类写com.mysql.cj.jdbc.Driver。

如果你用的是Maven项目，建议直接在pom.xml中锁定版本。如果你是不用构建工具的老项目，那就手动下载jar包放到WEB-INF/lib目录下。

1.2 驱动jar包的获取方式

这里分两种情况讲。

第一种，Maven项目。在pom.xml中加入依赖：

xml复制<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>8.0.33</version>
</dependency>

注意，mysql-connector-java这个坐标在8.0.31版本之后就停止更新了，官方改成了mysql-connector-j。如果你在旧教程里看到了mysql-connector-java，也能用，不过建议直接换成新坐标。

第二种，非Maven项目。你需要去MySQL官网下载Platform Independent版本，得到一个mysql-connector-j-8.0.33.zip压缩包，解压后把里面的jar文件拷贝到项目的lib目录，并在IDE中Add as Library。

新手最容易在这里犯的错是：jar包放在了lib目录，但没告诉IDE去加载它。在IntelliJ IDEA里，你需要右键jar包，选择"Add as Library"。在Eclipse里，需要右键项目 -> Build Path -> Configure Build Path -> Add External JARs。

1.3 确认MySQL服务端的连接参数

在写代码之前，先确认MySQL服务确实在监听端口。终端执行：

bash复制mysql -u root -p

如果进不去，先解决MySQL服务本身的问题。如果能进去，执行下面这条SQL确认端口：

sql复制SHOW VARIABLES LIKE 'port';

默认是3306，但有些人在安装时改过端口，或者服务器上有多个MySQL实例，这时候端口就不一定是3306了。Java代码里连错端口，报的错往往是Communications link failure或者Connection refused，非常容易让人误判成网络问题。

另外，确保你的MySQL用户允许远程连接。MySQL默认的root用户通常只允许localhost连接，如果你是通过局域网IP去连，需要创建一个允许远程访问的用户，或者修改root的host为%。但生产环境建议不要直接用root，而是创建专用账号，只授权业务库的权限。

sql复制CREATE USER 'app_user'@'%' IDENTIFIED BY 'StrongPass123';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

2. JDBC连接代码编写：从零到能跑的最短路径

2.1 标准六步连接法

JDBC连接数据库的核心代码逻辑其实非常固定，就是六步：

1. 加载驱动
2. 获取连接
3. 创建Statement或PreparedStatement
4. 执行SQL
5. 处理结果集
6. 关闭资源

用代码表示是这样：

java复制import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class JdbcDemo {
    public static void main(String[] args) {
        Connection conn = null;
        Statement stmt = null;
        ResultSet rs = null;
        try {
            // 1. 加载驱动
            Class.forName("com.mysql.cj.jdbc.Driver");

            // 2. 获取连接
            String url = "jdbc:mysql://localhost:3306/mydb"
                    + "?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8";
            String user = "root";
            String password = "your_password";
            conn = DriverManager.getConnection(url, user, password);

            // 3. 创建Statement
            stmt = conn.createStatement();

            // 4. 执行SQL
            rs = stmt.executeQuery("SELECT id, name FROM user");

            // 5. 处理结果集
            while (rs.next()) {
                System.out.println("id=" + rs.getInt("id")
                        + ", name=" + rs.getString("name"));
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            // 6. 关闭资源
            try { if (rs != null) rs.close(); } catch (Exception e) {}
            try { if (stmt != null) stmt.close(); } catch (Exception e) {}
            try { if (conn != null) conn.close(); } catch (Exception e) {}
        }
    }
}

这段代码是完整的可直接运行示例。注意finally块中的资源关闭顺序：先关ResultSet，再关Statement，最后关Connection，顺序反了会报错——虽然很多情况下连着GC也能回收，但如果你用的是连接池，不按顺序关闭会导致连接泄漏。

2.2 URL参数详解：每个参数都有它的脾气

JDBC的URL是很多人一知半解的地方。完整的URL格式是：

code复制jdbc:mysql://[host]:[port]/[database]?[parameter1=value1]&[parameter2=value2]

格式理清之后，?后面连接的参数可以自动拆解为三部分。逐一解释我实际遇到过的参数：

useSSL=false——本地开发调试，必须设置为false。如果MySQL服务端没有配置SSL证书，而代码默认开着SSL，连接时就会报Communications link failure。注意，MySQL 8.0默认是关闭SSL的，所以把useSSL=false写上总没错，生产环境如果确实要加密传输，需要另配证书。

serverTimezone=Asia/Shanghai——这个和所在时区绑定。不设置这个参数，MySQL 8.0会直接报The server time zone value '???ú±ê×??±??' is unrecognized，一脸懵对吧？其实这是因为MySQL服务器时区没有设置成UTC+8，驱动拿不到合法时区。解决办法有两种，一是代码层面加上serverTimezone=Asia/Shanghai，二是在MySQL服务端执行SET GLOBAL time_zone = '+8:00'。我更推荐顺手改服务端配置，一劳永逸。

characterEncoding=utf8——如果数据库里存了中文，这个参数必须设置。不设置的话，插入中文可能出现乱码或者Incorrect string value错误。注意，utf8和utf8mb4在MySQL里不是同一个东西，utf8mb4支持emoji和更多特殊字符。如果你的数据库字符集是utf8mb4，URL里建议写成characterEncoding=utf8就行，驱动会按utf8处理。

allowPublicKeyRetrieval=true——MySQL 8.0用caching_sha2_password认证插件时，如果连接时没有提前获取到服务端公钥，会报Public Key Retrieval is not allowed。这个问题的解法是在URL后追加allowPublicKeyRetrieval=true。但要注意，这个参数在公网生产环境下是有安全风险的，建议只在可信内网使用。

2.3 Statement和PreparedStatement的区别：别再用拼接SQL了

我在2.1节的示例代码中用的是Statement，方便展示最基础的流程。但在真实业务代码里，我强烈建议一律改用PreparedStatement。

两者的核心差别有三个：

• 性能。PreparedStatement会预编译SQL，如果同样结构的SQL要执行很多次（比如批量插入一万条数据），只预编译一次，后面的执行直接复用，性能有明显优势。
• 安全。Java后端最常见的漏洞之一就是SQL注入。Statement用字符串拼接SQL，用户输入恶意字符串就能改写你的SQL语义；PreparedStatement用占位符?传参，驱动会帮你做转义，从根上杜绝SQL注入。
• 可读性。业务SQL越复杂，用?占位符的方式比拼接一长串加号更清晰。

用PreparedStatement改写核心查询逻辑：

java复制String sql = "SELECT id, name FROM user WHERE age > ? AND city = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 18);
pstmt.setString(2, "上海");
ResultSet rs = pstmt.executeQuery();

注意，PreparedStatement的下标从1开始，不是从0开始，这是新手高频报错点。

3. 配置管理与连接池：别再每次请求都新建连接了

3.1 为什么不建议把连接参数硬编码在代码里

代码写多了你会慢慢意识到一个道理：凡是会变的东西，都不应该写死在代码里。

数据库IP、端口、用户名、密码，这些信息在开发环境、测试环境、生产环境往往不一样。每次发版都要改代码重新编译？这显然是灾难。而且，如果把代码提交到Git仓库，意味着数据库密码也跟着代码一起进了版本库，一旦仓库泄漏，数据库就裸奔了。

常用的做法是用配置文件。Java项目一般用properties或yaml文件。以db.properties为例：

properties复制jdbc.driver=com.mysql.cj.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/mydb?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8&allowPublicKeyRetrieval=true
jdbc.username=root
jdbc.password=your_password

然后在代码中用Properties类加载：

java复制Properties props = new Properties();
props.load(new FileInputStream("db.properties"));
String url = props.getProperty("jdbc.url");
String user = props.getProperty("jdbc.username");
String password = props.getProperty("jdbc.password");

如果你的项目用了Spring Boot，那更简单，直接在application.yml里配置。本质上，思路都是将易变信息从代码中剥离。

3.2 连接池原理与HikariCP实践

每次需要操作数据库就新建一个Connection，用完再关闭，在低并发场景下没问题。但一旦请求量上来，频繁创建和销毁连接的开销会非常明显。打个比方：你每次去超市都要先修一条路过去，买完东西再把路拆了，下次去再修一条。这种模式显然是巨大的浪费。

连接池的思路是：提前创建一批连接放在池子里，谁用谁来取，用完放回去。HikariCP是目前Java生态里性能最好的连接池，Spring Boot 2.x之后默认就是它。如果你不用Spring Boot，也可以单独使用。

引入依赖：

xml复制<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>4.0.3</version>
</dependency>

写一个简单的连接池工具类：

java复制import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

import javax.sql.DataSource;
import java.sql.Connection;

public class DbUtil {
    private static HikariDataSource dataSource;

    static {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb?useSSL=false&serverTimezone=Asia/Shanghai");
        config.setUsername("root");
        config.setPassword("your_password");
        config.setMaximumPoolSize(10);
        config.setMinimumIdle(5);
        config.setConnectionTimeout(30000);
        dataSource = new HikariDataSource(config);
    }

    public static Connection getConnection() throws Exception {
        return dataSource.getConnection();
    }
}

解释一下核心参数：

• maximumPoolSize：池中最大连接数。不是越大越好，连接数太多反而会拖垮数据库。一般按照((core_count * 2) + effective_spindle_count)的经验公式估算，但不同业务差异大，建议起步10~20，压测后调整。
• minimumIdle：空闲时保持的最小连接数。建议等于maximumPoolSize，避免流量洪峰时频繁创建连接。
• connectionTimeout：从池中借出连接的超时时间，单位毫秒，默认30秒。超过这个时间还借不到连接，会抛异常。连接池满再借连接时，这个参数就是最先被触发的错误来源。

3.3 连接池的好处：不只性能

连接池除了省去频繁创建销毁的开销，还有一个隐藏的好处：统一管理连接生命周期。当数据库重启、网络闪断，连接池会主动检测到失效连接并剔除，下次请求会拿到新的可用连接。如果不用连接池，你自己管理的Connection在数据库重启后就变成了废连接，代码拿着它执行SQL，就会报Connection is not available或者No operations allowed after connection closed这种莫名其妙的错。

很多看起来诡谲的线上问题，排查到最后都是因为没用连接池，或者连接池配置不合理。

4. 常见异常大盘点：每条都是实践出真知

4.1 ClassNotFoundException与No suitable driver

这两个异常是新手最容易遇到的第一步拦路虎。

• java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver——JVM压根没有找到驱动类。解决方案：确认jar包是否真的引入了，检查Maven依赖是否下载成功，或者手动添加jar到classpath。
• java.sql.SQLException: No suitable driver found for jdbc:mysql://...——URL格式不对或者驱动没有被正确加载。检查URL前缀是否是jdbc:mysql://，MySQL 8.x的驱动类加载语句是否写对。

一个有迷惑性的细节是：JDBC 4.0之后，驱动支持自动加载机制。只要classpath里有MySQL驱动jar包，DriverManager能自动识别，不需要显式调用Class.forName。但对于老版本JDK或特殊容器环境，显式加载仍然是最稳妥的，所以我习惯性地保留Class.forName这一行。

4.2 Communications link failure

这个异常可以说是Java连MySQL报错天花板级别的频率。它可能是：

• 网络不通，比如IP写错、防火墙拦截。
• MySQL端口错误或服务没启动。
• 连接被数据库拒绝，比如用户host限制。
• 等待连接超时（MySQL的wait_timeout默认8小时）。

排查的办法是层层递进的：先用ping看网络通不通，再用telnet ip 3306看端口通不通，最后在MySQL命令行里试着用同样的用户和密码远程连接一次。

如果是connect timed out，大概率是网络或防火墙问题。如果是Connection refused，大概率是MySQL服务没启动。如果是连接建立了但等了一会才报错，多留意wait_timeout——长时间空闲的连接会被MySQL服务端主动断开，Java这边不知道，再拿着这个连接执行SQL就会挂。解决方案还是那句话：用连接池，让连接池帮你清理失效连接。

4.3 Public Key Retrieval is not allowed

MySQL 8.0默认的认证插件是caching_sha2_password，当客户端用RSA公钥加密密码传输时，会请求服务端发送公钥。服务端出于安全考虑默认不主动发，于是客户端报错。

解决办法有两个：

• URL加参数allowPublicKeyRetrieval=true。
• 把用户的认证插件改成mysql_native_password：

sql复制ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';

我建议优先用后者，因为公钥检索在不可信网络上存在中间人攻击风险，能不用就不用。

4.4 Connection is not available / request timed out

这个错误通常来自连接池。连接池最大连接数设置得比较小，而你的代码在并发场景下把所有连接都借走了，还迟迟不归还，其他人再来借就必须等待，超过connectionTimeout就抛异常。

根源往往是连接泄漏：从连接池拿到的Connection没有在finally块中关闭。这种问题在代码review时很难发现，最好的方式是在代码里给连接池打开泄漏检测：

java复制config.setLeakDetectionThreshold(60000);

这个参数设为60秒，意味着某个连接借出超过60秒还没归还，HikariCP会在日志中输出告警，哪个方法拿的连接没还，一目了然。

4.5 中文乱码问题

中文乱码分两种情况：

• 存储到数据库就乱了：检查URL里是否加了characterEncoding=utf8。
• 读取出来乱了：检查数据库表、字段的字符集，是否和代码里的字符集一致。

最彻底的做法是建库时就指定好字符集：

sql复制CREATE DATABASE mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

表也统一指定：

sql复制CREATE TABLE user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50)
) DEFAULT CHARSET=utf8mb4;

Java代码、JDBC URL、MySQL库表，三者的字符集要一致，少一个环节都可能乱码。

4.6 常见问题速查表

5. 完整实操案例：从零跑通一个用户表查询

纸上谈兵没意思，我用一个完整案例把前面所有知识点串起来。

5.1 案例目标与数据库准备

我要做的是：用Java程序连接MySQL，查询一个用户表，按年龄筛选，把结果打印出来。

先在MySQL中建库建表并插入几条测试数据：

sql复制CREATE DATABASE IF NOT EXISTS demo_db DEFAULT CHARSET=utf8mb4;
USE demo_db;

CREATE TABLE IF NOT EXISTS t_user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    age INT,
    email VARCHAR(100)
);

INSERT INTO t_user (name, age, email) VALUES
('张三', 25, 'zhangsan@example.com'),
('李四', 30, 'lisi@example.com'),
('王五', 22, 'wangwu@example.com');

5.2 代码结构设计

这个案例虽然简单，但代码结构我也按实际项目的思路拆分了：

• db.properties：数据库配置。
• DbUtil.java：用HikariCP初始化连接池，提供静态方法获取连接。
• User.java：实体类，一张表一个Java类，字段一一对应。
• UserDao.java：数据访问层，负责执行SQL，把结果集封装成对象列表。
• Main.java：入口，调用DAO层方法，打印结果。

这样拆分的目的是：以后换数据库、改查询逻辑，改动范围都被隔离在单独的一层里，不会牵一发动全身。

5.3 各层代码实现

DbUtil.java：

java复制import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

import java.io.InputStream;
import java.sql.Connection;
import java.util.Properties;

public class DbUtil {
    private static final HikariDataSource dataSource;

    static {
        try {
            Properties props = new Properties();
            InputStream is = DbUtil.class.getClassLoader()
                    .getResourceAsStream("db.properties");
            props.load(is);

            HikariConfig config = new HikariConfig();
            config.setJdbcUrl(props.getProperty("db.url"));
            config.setUsername(props.getProperty("db.username"));
            config.setPassword(props.getProperty("db.password"));
            config.setMaximumPoolSize(10);
            config.setMinimumIdle(2);
            config.setConnectionTimeout(30000);
            config.setLeakDetectionThreshold(60000);
            dataSource = new HikariDataSource(config);
        } catch (Exception e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    public static Connection getConnection() throws Exception {
        return dataSource.getConnection();
    }
}

UserDao.java：

java复制import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.ArrayList;
import java.util.List;

public class UserDao {
    public List<User> findByAgeGreaterThan(int age) {
        String sql = "SELECT id, name, age, email FROM t_user WHERE age > ?";
        List<User> userList = new ArrayList<>();
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = DbUtil.getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setInt(1, age);
            rs = pstmt.executeQuery();
            while (rs.next()) {
                User user = new User();
                user.setId(rs.getInt("id"));
                user.setName(rs.getString("name"));
                user.setAge(rs.getInt("age"));
                user.setEmail(rs.getString("email"));
                userList.add(user);
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try { if (rs != null) rs.close(); } catch (Exception e) {}
            try { if (pstmt != null) pstmt.close(); } catch (Exception e) {}
            try { if (conn != null) conn.close(); } catch (Exception e) {}
        }
        return userList;
    }
}

Main.java：

java复制import java.util.List;

public class Main {
    public static void main(String[] args) {
        UserDao userDao = new UserDao();
        List<User> users = userDao.findByAgeGreaterThan(23);
        for (User user : users) {
            System.out.println(user);
        }
    }
}

输出结果应该是：

code复制User{id=1, name='张三', age=25, email='zhangsan@example.com'}
User{id=2, name='李四', age=30, email='lisi@example.com'}

这个案例是完美的起步模板。以后无论你的业务多复杂，核心结构都是这一套：获取连接 -> 预编译SQL -> 绑定参数 -> 执行 -> 解析结果 -> 关闭资源。

6. 进阶技巧：批量操作、事务处理与性能优化

6.1 批量插入的正确姿势

批量插入时，一条一条executeUpdate是性能灾难。JDBC提供了批量处理机制。

java复制String sql = "INSERT INTO t_user (name, age, email) VALUES (?, ?, ?)";
PreparedStatement pstmt = conn.prepareStatement(sql);
for (int i = 0; i < 10000; i++) {
    pstmt.setString(1, "user_" + i);
    pstmt.setInt(2, 20 + (i % 20));
    pstmt.setString(3, "user_" + i + "@example.com");
    pstmt.addBatch();
    if (i % 1000 == 0) {
        pstmt.executeBatch();
    }
}
pstmt.executeBatch();

注意，每攒到一定数量手动提交一次Batch，既避免内存积压，又提升执行效率。这里executeBatch()会把攒下的所有SQL一次性发给数据库执行。

6.2 事务的边界要清晰

JDBC默认是自动提交模式，也就是每条SQL语句执行完自动commit。但在转账这种场景里，A账户扣钱和B账户加钱必须是一个原子操作，要么都成功，要么都失败。

java复制conn = DbUtil.getConnection();
conn.setAutoCommit(false);
try {
    // 执行扣款SQL
    // 执行入账SQL
    conn.commit();
} catch (Exception e) {
    conn.rollback();
    throw e;
} finally {
    conn.setAutoCommit(true);
    if (conn != null) conn.close();
}

有个小细节很多人忽略：事务操作完之后，一定要把autoCommit设回true，否则这个连接归还给连接池后，下一个使用者拿到它时会发现自动提交被关了，导致普通SQL迟迟不生效，产生非常隐蔽的bug。

6.3 用连接池和预编译并不等于高枕无忧

我给某些内部系统做过性能排查，最后发现的瓶颈不是连接池也不是SQL预编译，而是rs.next()之后逐行处理数据的逻辑太慢，把连接占着不放。调优优先级应该是先查慢SQL，再看连接池参数，最后才看代码逻辑。顺序反了，调了三天也调不出效果。

排查慢SQL的方式很简单：MySQL开启慢查询日志，把执行时间超过阈值的SQL记录下来。可以执行：

sql复制SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

这样超过1秒的SQL都会被记录到日志文件里。把慢SQL捞出来，用EXPLAIN分析执行计划，看有没有走索引、有没有全表扫描。这一套流程是后端开发排查数据库问题的基本功。

7. 安全红线：密码管理、SQL注入与连接加密

7.1 数据库密码不要出现在日志里

这是一个很隐晦但很常见的问题。有些团队为了方便排查，把jdbc:mysql://user:password@host:port/db这种写法放进代码或者日志，或者配置文件里密码被意外打印。一旦日志系统被拖库，数据库密码就暴露了。

建议的做法是：配置文件中的密码用环境变量或外部配置中心注入，代码中严禁打印URL全量信息，日志里如果确需打印数据库地址，把密码部分打码。

7.2 SQL注入真的不难防

本章反复强调PreparedStatement，归根结底是为了防SQL注入。我见过一些初学者认为"我做了参数校验，把单引号过滤了就行"，这种思路是典型的自欺欺人。数据库解析器的复杂度和攻击者的想象力远超你的过滤规则，唯一稳妥的方式就是参数化查询。

7.3 生产环境的SSL连接

生产环境如果对数据传输有加密要求，需要MySQL服务端提前配置SSL证书。此时URL参数中的useSSL=true，并显式指定verifyServerCertificate=true和相关证书路径。具体配置步骤比较复杂，不是一句两句说得清，但核心原则是：千万不要图省事，在内网可以适当放松，公网数据传输必须走加密或至少走可信内网加白名单。

8. 写在最后的经验笔记

最后分享一个我自己的体会：连接数据库这种基础能力，越早系统弄懂越好。做Java后端这几年，我见过太多因为不熟悉JDBC底层而踩坑的案例，比如用Statement拼接SQL导致线上数据异常、连接池参数不合法导致服务雪崩、时区不对导致时间数据偏差八小时。这些坑在教程里都查不到，但在实际业务中一个比一个疼。

有个实用小技巧：调试JDBC连接问题时，先别写Java代码，直接在命令行用MySQL客户端连接一次。如果命令行能连上而Java连不上，问题基本锁定在驱动配置或URL参数；如果命令行也连不上，就别折腾代码了，乖乖检查服务端。这个三板斧的排查思路能帮你省掉至少一半的调试时间。

这套知识与技术栈的衔接也很好。弄通了JDBC，再去看MyBatis、Spring Data JPA这些ORM框架时，你会恍然大悟——它们本质上都是在JDBC之上做了一层封装。底层那套连接管理、参数绑定、事务控制能力，你真的理解过后，学习任何上层框架都是降维打击。