手写JDBC连接MySQL大概是每个Java后端程序员都绕不过去的第一道门槛。我见过太多人卡在这个看似简单的环节上照着教程敲了代码报错却千奇百怪一会儿时区不对一会儿SSL警告一会儿又是Public Key Retrieval不允许最后连“拒绝连接”都冒出来了。这篇文章我想把JDBC连接MySQL这件事从头讲透先从底层原理说起再给一套完整可跑的代码然后把高频报错逐个拆开从现象一路追到根因最后聊一聊连接池、事务和连接参数的取舍。不管你是刚入门的学生还是已经被连接问题折腾过的在职开发这篇文章都能帮你少走几个月的弯路。先说清楚一件事这篇文章不是简单的“CV一下就能跑”的速成教程我更想帮你建立起排查问题的思路。因为连接报错这种东西网上答案一大把但大多数都是让你复制粘贴某个参数根本不告诉你为什么。而实际情况是你不会总遇到同一个错换个环境、换个数据库版本报错就变了。只有把原理吃透你才能做到举一反三。1. 连接MySQL之前先把JDBC的底层逻辑讲透1.1 JDBC是接口驱动是实现别把两者搞混很多同学以为import java.sql.*就是在用JDBC了其实这里面有个关键区分Connection、Statement、ResultSet这些全是接口真正干活的是驱动包里的实现类。换句话说JDBC是Java官方定出来的一套“数据库操作标准”它本身不连接任何数据库而MySQL的Connector/J才是那个真正帮你和MySQL对话的翻译官。打一个生活化的比方JDBC就像插座设计标准驱动就是插头。标准规定了插头长什么样、怎么插进去但能不能通上电取决于插头本身的质量和匹配度。所以你在代码里只用java.sql.Connection做编译并不代表项目已经能连上MySQL了还得保证运行时classpath里有对应的驱动。这也是为什么新手容易踩一个坑代码明明是从教程里抄的却报ClassNotFoundException因为教程用的是MySQL 8的驱动类名而项目里放的是5.x的驱动包或者干脆没把jar包放到WEB-INF/lib下面。这种报错在后续章节我会专门展开这里先记住一个结论版本匹配和classpath问题比代码逻辑更容易让你翻车。1.2 一条连接建立的完整链路TCP、TLS与MySQL握手我曾经一度把“建立JDBC连接”想得很简单以为DriverManager一调用连接就像变魔术一样出现了。直到排查一个内网连接慢的问题才逼着自己去翻通信链路发现一条普通连接的建立实际要经历这么几步驱动解析连接URL拆出主机名、端口、数据库名和参数通过DNS解析主机名得到IP然后发起TCP三次握手如果URL里开启了SSL还要先做TLS协商交换证书、确定加密套件走MySQL自己的握手协议服务端下发版本信息和认证插件名客户端用对应插件加密密码完成认证服务端返回OK包建立会话之后才能执行SQL。理解这条链路特别重要因为你会发现不同报错其实对应不同阶段。Connection refused是TCP阶段挂了SSL connection error是TLS协商挂了Access denied是认证阶段挂了Unknown database是认证通过后选库时挂了。以后看到报错先判断它发生在哪一层排查范围直接缩小一大半。1.3 连接URL拆解host、port、database与参数连接URL是整个JDBC配置的灵魂也是最容易写错的部分。我们先拆一条最典型的jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8jdbc:mysql://是协议前缀固定写法缺少它驱动根本不会认127.0.0.1是MySQL所在主机localhost也可以但两者不一定等价后面排查会提到3306是MySQL默认端口如果你改过my.cnf里的port这里必须跟着改test_db是要连接的数据库名可以省略不写但省略后需要在代码里执行USE test_db才能操作具体库?后面的参数用分隔配置项之间没有先后关系。这里特别提醒一点URL里如果出现特殊字符比如想把时区写成GMT8号会被解析成空格必须写成GMT%2B8。这也是为什么官方推荐用Asia/Shanghai而不是GMT8的原因之一省去转义烦恼。1.4 Class.forName到底还要不要写老教材里都有这么一行Class.forName(com.mysql.jdbc.Driver)。JDBC 4.0之后驱动注册改成了SPI机制驱动包里的META-INF/services已经声明了驱动类理论上你不写这行也能自动加载。但我个人建议代码里还是写上尤其是com.mysql.cj.jdbc.Driver这个新类名。理由有两个一是兼容性某些老Web容器或特殊部署环境对SPI扫描支持不完整二是可读性看到这行代码团队里任何人立刻知道项目用的是哪个驱动。反正就一行代码不会引入任何副作用。2. 从零跑通一条JDBC连接驱动、代码与验证2.1 选对驱动Maven坐标、jar包下载与版本匹配先保证一点你的MySQL能通过命令行正常登录比如mysql -u root -p能进去。如果命令行都连不上那问题不在JDBC而在MySQL本身的安装配置上这一步先排除。接下来是驱动选择。这里有一个很容易踩坑的版本变化从MySQL Connector/J 8.0.31开始Maven坐标发生了调整。老写法是dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.49/version /dependency新写法是dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency同时驱动类名也从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver。如果你在MySQL 8环境继续用5.1.x的驱动通常会报No suitable driver或者认证失败因为5.1驱动根本不认识MySQL 8的caching_sha2_password认证插件。版本匹配这块没有太多黑魔法记住两个结论MySQL 8.0环境请用8.x的驱动MySQL 5.7环境用5.1.x或8.x驱动都行但上了8.x驱动后URL参数要按8.x的规范写。还有Maven项目里要留意依赖传递比如HikariCP或MyBatis可能间接引入了一个旧版驱动导致classpath里同时存在多个版本的驱动类这种重复依赖引发的报错最隐蔽不好查。2.2 最小可运行代码五分钟跑通第一条连接有了驱动依赖之后最直接的验证方式就是写一个main方法跑起来。我习惯先用JDK自带的DriverManager跑通不引入任何框架因为这样可以确定问题是出在连接环节还是出在框架配置环节。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) { String url jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8; String username root; String password 123456; Class.forName(com.mysql.cj.jdbc.Driver); try (Connection conn DriverManager.getConnection(url, username, password); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT 1)) { if (rs.next()) { System.out.println(连接成功SELECT 1结果 rs.getInt(1)); } } catch (Exception e) { e.printStackTrace(); } } }这段代码用的是try-with-resources执行完会自动关闭ResultSet、Statement和Connection省得写一堆finally。有一个细节关闭顺序必须是后开先关也就是先关ResultSet再关Statement最后关Connection。虽然底层驱动通常做了容错但如果你用连接池把没关闭的Statement还给池子资源泄漏会在高并发下慢慢积累最后把数据库连接数打满。我建议你跑这段代码前先想清楚一个逻辑SELECT 1只是验证连通性它不代表你MySQL里的业务库没问题。如果你连test库都还没创建把URL里的数据库名去掉也能连但那样只能执行SELECT 1之类不依赖库的操作。2.3 连接信息抽成配置写一个不丢人的DBUtil工具类实际开发中没人会把数据库账号密码硬编码在代码里。一是环境不同本地、测试、生产连接信息不一样二是密码不该出现在代码仓库里。所以哪怕是个demo我也建议从一开始就养成好习惯把连接信息放到配置文件里。在src/main/resources下新建db.propertiesdb.drivercom.mysql.cj.jdbc.Driver db.urljdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 db.usernameroot db.password123456然后是工具类import java.io.InputStream; import java.sql.Connection; import java.sql.DriverManager; import java.util.Properties; public class DBUtil { private static String url; private static String username; private static String password; static { try (InputStream in DBUtil.class.getClassLoader() .getResourceAsStream(db.properties)) { Properties props new Properties(); props.load(in); url props.getProperty(db.url); username props.getProperty(db.username); password props.getProperty(db.password); Class.forName(props.getProperty(db.driver)); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws Exception { return DriverManager.getConnection(url, username, password); } }注意我把Class.forName放在静态块里这样类一加载就完成驱动注册。配置文件加载如果在静态块里抛异常会转成ExceptionInInitializerError程序启动就能发现问题而不是等到真正调用getConnection时才报错。这个细节算是一个小小的经验让错误尽早暴露。2.4 验证连接成功的正确姿势很多人习惯在代码里打印conn ! null来验证连接成功。说实话这不算错但不够专业。我推荐几个更好用的验证方式执行SELECT 1最轻量不依赖任何业务表在MySQL里跑SHOW PROCESSLIST;能看到当前连接数和来源IP用SELECT CONNECTION_ID();拿到当前连接ID确认自己操作的是哪个连接。另外我强烈建议在写Java代码之前先用你常用的数据库客户端工具Navicat、DBeaver、DataGrip都行连一下MySQL。如果图形工具能连上而Java连不上那问题基本锁定在连接URL参数或代码段如果图形工具也连不上那就去查MySQL本身的配置别在Java这边瞎折腾。分而治之是排查连接问题最有效的策略。3. 高频连接报错全拆解从现象一路查到根因3.1 时区报错The server time zone value Öйú±ê׼ʱ¼ä is unrecognized这是MySQL 8时代最经典的报错之一报错信息里经常出现乱码或者一长串“is unrecognized or represents more than one time zone”。根因是MySQL 8.x的时区默认跟踪系统设置而很多国内装机的Windows系统时区显示为“中国标准时间”但这个值在Java时区库里没有对应的标准ID驱动解析失败。这个错还有一个变体Info图标下会提示The server time zone value ???±???±???? is unrecognized乱码其实是字符集问题导致时区名显示异常。解决办法最直接jdbc:mysql://127.0.0.1:3306/test_db?serverTimezoneAsia/Shanghai也能在MySQL侧改全局时区SET GLOBAL time_zone 08:00;但我个人更推荐改连接URL原因很简单不动线上数据库配置影响面小。顺序上先把URL加上serverTimezone如果加了还是报错再去数据库侧查time_zone变量。3.2 SSL警告与连接失败从一段告警日志说起MySQL 8.x的驱动默认把SSL开关打开了。于是很多人在控制台看到这么一行WARN: Establishing SSL connection without servers identity verification is discouraged这行Warning本身不致命但它透露了一个事实连接确实建立了只是拿着一个自签名证书在做TLS协商而没有做证书信任校验。对开发环境来说确实没必要对生产环境而言又没有安全感非常尴尬。如果SSL协商彻底失败报错会升级成SQLNonTransientConnectionException: SSL connection error。两种处理方式开发/内网环境URL加useSSLfalse关闭加密生产/公网环境不要简单关掉而是配置JVM信任MySQL服务端证书或者用tlsVersionTLSv1.2显式指定协议版本。我之前就遇到过一次诡异情况同一套代码在自己笔记本连测试库一切正常部署到服务器后连同一台MySQL却报SSL错误。最后发现是服务器JDK版本较低默认支持的TLS版本跟MySQL 8要求的不匹配在URL里显式指定tlsVersionTLSv1.2才解决。所以看到SSL相关报错多想一想不只是开不开SSL的问题还可能是加密套件和TLS版本匹配的问题。3.3 Public Key Retrieval is not allowedMySQL 8认证插件埋的坑这个报错算是我见过最迷惑的一个尤其当你用Navicat能连上、写Java却报错时整个人都会是懵的。原因在于MySQL 8默认用的认证插件是caching_sha2_password而不是5.x时代的mysql_native_password。当客户端和服务端之间没有走SSL时这个插件要求客户端从服务端获取RSA公钥来加密密码。而驱动出于安全考虑默认禁止自动获取公钥于是直接报Public Key Retrieval is not allowed。两个方向的解决方案方案一连接URL加参数allowPublicKeyRetrievaltrueuseSSLfalse方案二把数据库用户的认证插件改回去ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES;只提醒一句allowPublicKeyRetrievaltrue本质是允许客户端在非SSL连接下获取服务器公钥这个动作天然存在中间人攻击的风险。如果你所在网络环境不可信老老实实配SSL证书别图省事直接加这个参数。我自己在内网开发机上是加的生产环境绝不这么干。3.4 Communications link failure网络层的完整排查链路Communications link failure后面通常会跟着一串细节比如Connection refused或Connection timed out。前者说明目标主机的端口根本没开后者说明网络包都发不到对方那里。我分享一下自己的排查顺序一条一条过所有步骤都在命令行里完成第一步确认MySQL进程在跑。Linux用ps -ef | grep mysqldWindows看服务列表或tasklist | findstr mysqld。进程不在后面什么都不用查。第二步确认端口在监听。Linux用netstat -tlnp | grep 3306看监听地址是不是只有127.0.0.1。MySQL的默认配置里bind-address127.0.0.1会导致只有本机能连远程一律拒绝。第三步测网络连通性。先ping host确认主机在线再telnet host 3306或nc -vz host 3306测端口。如果telnet连不通说明TCP层就过不去继续往下查。第四步检查防火墙和安全组。Linux上看看iptables -L -n和firewall-cmd --list-all云服务器还要去控制台看安全组规则有没有放行3306端口。这里有个容易忽视的点很多云厂商的安全组默认不放行MySQL端口本地防火墙也开了但安全组没放行一样连不上。第五步检查MySQL配置里是不是开了skip-networking。这个参数直接禁用TCP监听配置了它怎么放行防火墙都没用。这五步走下来基本能找到90%以上的Communications link failure。我还建议在连接URL里加connectTimeout5000避免网络黑洞时线程傻等几十秒。这个参数属于JDBC驱动层面的跟MySQL服务端没关系。3.5 Access denied与ClassNotFoundException两类迷惑性极强的报错Access denied for user rootlocalhost (using password: YES)这个报错很常见但原因并不总是密码错误。梳理成三种情况密码确实打错了命令行先验证用户名/主机组合不匹配。MySQL的用户名实际上是“userhost”这个二元组rootlocalhost和root%是两个完全不同的用户。你在远程连的时候MySQL会找匹配的host记录找不到就拒绝认证插件不匹配。如果你把用户改成mysql_native_password之后没刷新权限或者反过来也可能出现Access denied。遇到这个错先命令行登录排除密码问题再SELECT user, host, plugin FROM mysql.user;查一下用户表看看目标主机的授权记录是否存在。这个思路比盲目重置密码强很多。再说ClassNotFoundException。如果你的报错是ClassNotFoundException: com.mysql.jdbc.Driver其实不是“驱动坏了”而是驱动类的全限定名跟代码里写的不一致。老驱动类名是com.mysql.jdbc.Driver8.x驱动类名是com.mysql.cj.jdbc.Driver。另一个常见原因是jar包根本没部署到位用Maven的话检查scope是不是runtime、是不是被排除掉了用Tomcat部署的话看WEB-INF/lib。还有一种No suitable driver found for jdbc:mysql...的报错通常和ClassNotFoundException同源classpath里没有驱动或者URL前缀写错比如写成了jdbc:mysql少了协议分隔符。检查URL拼写和jar包依赖比改代码更有效。4. 连接只是开始事务、连接池与连接参数调优4.1 JDBC事务为什么默认要关掉AutoCommitJDBC默认是自动提交的也就是每执行一条SQLMySQL就把事务提交了。这在单条SQL场景下没什么问题但在转账、下单这种需要多步操作的业务里就是灾难第一步扣钱成功第二步加钱失败钱就凭空少了。手动控制事务的标准写法Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 执行扣款SQL // 执行入账SQL conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); // 复位避免归还连接池时带着事务状态 conn.close(); }这里踩过的坑是用连接池时如果事务里抛了异常但忘记调rollback连接归还后还残留着未提交事务和锁定资源轻则连接复用时报错重则把数据库锁住。我建议在finally里复位autoCommit并把close也放进来这是连接池场景下的好习惯。关于隔离级别多数项目默认用TRANSACTION_REPEATABLE_READ就够了MySQL的默认就是它。你可以在连接创建后调用conn.setTransactionIsolation()调整但不要随手改隔离级别越高并发性能损失越大。这个属于事务设计范畴回头可以单独写一篇。4.2 连接池生产环境没人直接用DriverManager用DriverManager每次getConnection实际上就是走一遍完整建连流程TCP握手、MySQL握手、认证、建会话。单次耗时从几十毫秒到几百毫秒不定。业务并发一上来光建连接就会把数据库负载拉高。连接池的思路很简单提前建立一批连接反复复用不销毁空闲连接。目前Java世界最推荐的是HikariCP配置简单性能好。我用Spring Boot项目时常用这套配置HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/Shanghai); config.setUsername(root); config.setPassword(123456); config.setDriverClassName(com.mysql.cj.jdbc.Driver); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setMaxLifetime(1800000); // 30分钟 config.setConnectionTimeout(30000); HikariDataSource dataSource new HikariDataSource(config);有几个参数容易理解错。MaximumPoolSize不是越大越好连接数超过数据库负载能力反而拖慢整体MaxLifetime一定要小于MySQL的wait_timeout。MySQL默认8小时回收空闲连接如果连接池里的连接生命周期比它还长你拿到的连接其实已经被服务端关闭了执行第一条SQL就会报Connection is not available或者Broken pipe。HikariCP官方建议MaxLifetime设置在25到30分钟比较稳妥。4.3 一张表说清高频连接参数的取舍日常排查连接问题时很大一部分都是URL参数引起的。我把实践中高频使用的参数整理成一张表方便你备查。参数默认值作用实战建议useSSLtrue8.x是否启用TLS加密内网开发false生产公网建议true并配证书serverTimezone无服务端时区MySQL 8必须显式指定一般用Asia/ShanghaicharacterEncodingUTF-8客户端字符集保持utf8不要随便改成gbkconnectTimeout取决于驱动TCP连接超时建议3000~5000ms快速失败socketTimeout0无限socket读写超时有慢SQL时按业务需求设置防止线程挂死rewriteBatchedStatementsfalse批量重写做批量插入时改true性能提升明显allowPublicKeyRetrievalfalse允许获取RSA公钥非SSL且用户是caching_sha2_password时设truecachePrepStmtsfalse缓存预编译语句高频SQL场景建议开启useServerPrepStmtsfalse使用服务端预编译配合cachePrepStmts一起用才有意义插一段个人经验我看到不少人一遇到连接报错就喜欢在URL后面堆参数useSSLfalseuseUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue一串问题看着头疼。其实大部分场景只需要三四个参数。参数不是越多越好每加一个参数都意味着驱动要额外做一件事也可能引入新的兼容问题。调试时先加最必要的那一两个测通了再逐步加。4.4 本地连不上远程MySQL这四关必须逐一过本地代码联调时经常遇到“在服务器本机能连MySQL从外面连不上”的情况。这个问题跟JDBC本身没关系但从JDBC报错倒推时几乎都会归结到下面四关第一关MySQL监听地址。默认bind-address是127.0.0.1必须改成0.0.0.0或内网IP地址然后重启MySQL。这个改动意味着MySQL暴露在更多网络接口上生产环境要配合防火墙一起收紧。第二关防火墙和安全组。Linux先执行firewall-cmd --permanent --add-port3306/tcp再firewall-cmd --reload云服务器还要记得在控制台安全组里放行。这一关经常和第一关一起出事少一个都白搭。第三关数据库用户的host。如果用户是rootlocalhost远程来的请求不会匹配这条记录。最直接的解决方式是新建一个用于远程的应用账号CREATE USER app% IDENTIFIED BY StrongPass123; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO app%; FLUSH PRIVILEGES;%表示任意主机实际生产可以精确到某个IP网段比如10.10.8.%减少暴露面。第四关网络连通性。上面三关都过了还要确认两台机器之间真的能通。telnet server-ip 3306是最快的方法。如果telnet通了但Java还连不上再看连接URL的主机名是不是被DNS解析到了别的IP。这些年我帮同事排查远程连接问题90%以上都出在这四关里而且经常是几关一起出问题。所以建议按顺序过一遍而不是猜来猜去。最后再分享一个小技巧调试连接问题时先把MySQL的general_log打开能看到每个连接的完整握手过程SET GLOBAL general_log ON;排查完再关掉。之前有一次怎么都查不到拒绝原因打开log才发现是服务器在做反向DNS解析导致握手超时这种问题光靠猜是永远猜不出来的。希望这篇从原理到排错、再到进阶的流程能让你以后遇到类似问题时有章可循。
手写JDBC连接MySQL大概是每个Java后端程序员都绕不过去的第一道门槛。我见过太多人卡在这个看似简单的环节上照着教程敲了代码报错却千奇百怪一会儿时区不对一会儿SSL警告一会儿又是Public Key Retrieval不允许最后连“拒绝连接”都冒出来了。这篇文章我想把JDBC连接MySQL这件事从头讲透先从底层原理说起再给一套完整可跑的代码然后把高频报错逐个拆开从现象一路追到根因最后聊一聊连接池、事务和连接参数的取舍。不管你是刚入门的学生还是已经被连接问题折腾过的在职开发这篇文章都能帮你少走几个月的弯路。先说清楚一件事这篇文章不是简单的“CV一下就能跑”的速成教程我更想帮你建立起排查问题的思路。因为连接报错这种东西网上答案一大把但大多数都是让你复制粘贴某个参数根本不告诉你为什么。而实际情况是你不会总遇到同一个错换个环境、换个数据库版本报错就变了。只有把原理吃透你才能做到举一反三。1. 连接MySQL之前先把JDBC的底层逻辑讲透1.1 JDBC是接口驱动是实现别把两者搞混很多同学以为import java.sql.*就是在用JDBC了其实这里面有个关键区分Connection、Statement、ResultSet这些全是接口真正干活的是驱动包里的实现类。换句话说JDBC是Java官方定出来的一套“数据库操作标准”它本身不连接任何数据库而MySQL的Connector/J才是那个真正帮你和MySQL对话的翻译官。打一个生活化的比方JDBC就像插座设计标准驱动就是插头。标准规定了插头长什么样、怎么插进去但能不能通上电取决于插头本身的质量和匹配度。所以你在代码里只用java.sql.Connection做编译并不代表项目已经能连上MySQL了还得保证运行时classpath里有对应的驱动。这也是为什么新手容易踩一个坑代码明明是从教程里抄的却报ClassNotFoundException因为教程用的是MySQL 8的驱动类名而项目里放的是5.x的驱动包或者干脆没把jar包放到WEB-INF/lib下面。这种报错在后续章节我会专门展开这里先记住一个结论版本匹配和classpath问题比代码逻辑更容易让你翻车。1.2 一条连接建立的完整链路TCP、TLS与MySQL握手我曾经一度把“建立JDBC连接”想得很简单以为DriverManager一调用连接就像变魔术一样出现了。直到排查一个内网连接慢的问题才逼着自己去翻通信链路发现一条普通连接的建立实际要经历这么几步驱动解析连接URL拆出主机名、端口、数据库名和参数通过DNS解析主机名得到IP然后发起TCP三次握手如果URL里开启了SSL还要先做TLS协商交换证书、确定加密套件走MySQL自己的握手协议服务端下发版本信息和认证插件名客户端用对应插件加密密码完成认证服务端返回OK包建立会话之后才能执行SQL。理解这条链路特别重要因为你会发现不同报错其实对应不同阶段。Connection refused是TCP阶段挂了SSL connection error是TLS协商挂了Access denied是认证阶段挂了Unknown database是认证通过后选库时挂了。以后看到报错先判断它发生在哪一层排查范围直接缩小一大半。1.3 连接URL拆解host、port、database与参数连接URL是整个JDBC配置的灵魂也是最容易写错的部分。我们先拆一条最典型的jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8jdbc:mysql://是协议前缀固定写法缺少它驱动根本不会认127.0.0.1是MySQL所在主机localhost也可以但两者不一定等价后面排查会提到3306是MySQL默认端口如果你改过my.cnf里的port这里必须跟着改test_db是要连接的数据库名可以省略不写但省略后需要在代码里执行USE test_db才能操作具体库?后面的参数用分隔配置项之间没有先后关系。这里特别提醒一点URL里如果出现特殊字符比如想把时区写成GMT8号会被解析成空格必须写成GMT%2B8。这也是为什么官方推荐用Asia/Shanghai而不是GMT8的原因之一省去转义烦恼。1.4 Class.forName到底还要不要写老教材里都有这么一行Class.forName(com.mysql.jdbc.Driver)。JDBC 4.0之后驱动注册改成了SPI机制驱动包里的META-INF/services已经声明了驱动类理论上你不写这行也能自动加载。但我个人建议代码里还是写上尤其是com.mysql.cj.jdbc.Driver这个新类名。理由有两个一是兼容性某些老Web容器或特殊部署环境对SPI扫描支持不完整二是可读性看到这行代码团队里任何人立刻知道项目用的是哪个驱动。反正就一行代码不会引入任何副作用。2. 从零跑通一条JDBC连接驱动、代码与验证2.1 选对驱动Maven坐标、jar包下载与版本匹配先保证一点你的MySQL能通过命令行正常登录比如mysql -u root -p能进去。如果命令行都连不上那问题不在JDBC而在MySQL本身的安装配置上这一步先排除。接下来是驱动选择。这里有一个很容易踩坑的版本变化从MySQL Connector/J 8.0.31开始Maven坐标发生了调整。老写法是dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.49/version /dependency新写法是dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency同时驱动类名也从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver。如果你在MySQL 8环境继续用5.1.x的驱动通常会报No suitable driver或者认证失败因为5.1驱动根本不认识MySQL 8的caching_sha2_password认证插件。版本匹配这块没有太多黑魔法记住两个结论MySQL 8.0环境请用8.x的驱动MySQL 5.7环境用5.1.x或8.x驱动都行但上了8.x驱动后URL参数要按8.x的规范写。还有Maven项目里要留意依赖传递比如HikariCP或MyBatis可能间接引入了一个旧版驱动导致classpath里同时存在多个版本的驱动类这种重复依赖引发的报错最隐蔽不好查。2.2 最小可运行代码五分钟跑通第一条连接有了驱动依赖之后最直接的验证方式就是写一个main方法跑起来。我习惯先用JDK自带的DriverManager跑通不引入任何框架因为这样可以确定问题是出在连接环节还是出在框架配置环节。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) { String url jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8; String username root; String password 123456; Class.forName(com.mysql.cj.jdbc.Driver); try (Connection conn DriverManager.getConnection(url, username, password); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT 1)) { if (rs.next()) { System.out.println(连接成功SELECT 1结果 rs.getInt(1)); } } catch (Exception e) { e.printStackTrace(); } } }这段代码用的是try-with-resources执行完会自动关闭ResultSet、Statement和Connection省得写一堆finally。有一个细节关闭顺序必须是后开先关也就是先关ResultSet再关Statement最后关Connection。虽然底层驱动通常做了容错但如果你用连接池把没关闭的Statement还给池子资源泄漏会在高并发下慢慢积累最后把数据库连接数打满。我建议你跑这段代码前先想清楚一个逻辑SELECT 1只是验证连通性它不代表你MySQL里的业务库没问题。如果你连test库都还没创建把URL里的数据库名去掉也能连但那样只能执行SELECT 1之类不依赖库的操作。2.3 连接信息抽成配置写一个不丢人的DBUtil工具类实际开发中没人会把数据库账号密码硬编码在代码里。一是环境不同本地、测试、生产连接信息不一样二是密码不该出现在代码仓库里。所以哪怕是个demo我也建议从一开始就养成好习惯把连接信息放到配置文件里。在src/main/resources下新建db.propertiesdb.drivercom.mysql.cj.jdbc.Driver db.urljdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 db.usernameroot db.password123456然后是工具类import java.io.InputStream; import java.sql.Connection; import java.sql.DriverManager; import java.util.Properties; public class DBUtil { private static String url; private static String username; private static String password; static { try (InputStream in DBUtil.class.getClassLoader() .getResourceAsStream(db.properties)) { Properties props new Properties(); props.load(in); url props.getProperty(db.url); username props.getProperty(db.username); password props.getProperty(db.password); Class.forName(props.getProperty(db.driver)); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws Exception { return DriverManager.getConnection(url, username, password); } }注意我把Class.forName放在静态块里这样类一加载就完成驱动注册。配置文件加载如果在静态块里抛异常会转成ExceptionInInitializerError程序启动就能发现问题而不是等到真正调用getConnection时才报错。这个细节算是一个小小的经验让错误尽早暴露。2.4 验证连接成功的正确姿势很多人习惯在代码里打印conn ! null来验证连接成功。说实话这不算错但不够专业。我推荐几个更好用的验证方式执行SELECT 1最轻量不依赖任何业务表在MySQL里跑SHOW PROCESSLIST;能看到当前连接数和来源IP用SELECT CONNECTION_ID();拿到当前连接ID确认自己操作的是哪个连接。另外我强烈建议在写Java代码之前先用你常用的数据库客户端工具Navicat、DBeaver、DataGrip都行连一下MySQL。如果图形工具能连上而Java连不上那问题基本锁定在连接URL参数或代码段如果图形工具也连不上那就去查MySQL本身的配置别在Java这边瞎折腾。分而治之是排查连接问题最有效的策略。3. 高频连接报错全拆解从现象一路查到根因3.1 时区报错The server time zone value Öйú±ê׼ʱ¼ä is unrecognized这是MySQL 8时代最经典的报错之一报错信息里经常出现乱码或者一长串“is unrecognized or represents more than one time zone”。根因是MySQL 8.x的时区默认跟踪系统设置而很多国内装机的Windows系统时区显示为“中国标准时间”但这个值在Java时区库里没有对应的标准ID驱动解析失败。这个错还有一个变体Info图标下会提示The server time zone value ???±???±???? is unrecognized乱码其实是字符集问题导致时区名显示异常。解决办法最直接jdbc:mysql://127.0.0.1:3306/test_db?serverTimezoneAsia/Shanghai也能在MySQL侧改全局时区SET GLOBAL time_zone 08:00;但我个人更推荐改连接URL原因很简单不动线上数据库配置影响面小。顺序上先把URL加上serverTimezone如果加了还是报错再去数据库侧查time_zone变量。3.2 SSL警告与连接失败从一段告警日志说起MySQL 8.x的驱动默认把SSL开关打开了。于是很多人在控制台看到这么一行WARN: Establishing SSL connection without servers identity verification is discouraged这行Warning本身不致命但它透露了一个事实连接确实建立了只是拿着一个自签名证书在做TLS协商而没有做证书信任校验。对开发环境来说确实没必要对生产环境而言又没有安全感非常尴尬。如果SSL协商彻底失败报错会升级成SQLNonTransientConnectionException: SSL connection error。两种处理方式开发/内网环境URL加useSSLfalse关闭加密生产/公网环境不要简单关掉而是配置JVM信任MySQL服务端证书或者用tlsVersionTLSv1.2显式指定协议版本。我之前就遇到过一次诡异情况同一套代码在自己笔记本连测试库一切正常部署到服务器后连同一台MySQL却报SSL错误。最后发现是服务器JDK版本较低默认支持的TLS版本跟MySQL 8要求的不匹配在URL里显式指定tlsVersionTLSv1.2才解决。所以看到SSL相关报错多想一想不只是开不开SSL的问题还可能是加密套件和TLS版本匹配的问题。3.3 Public Key Retrieval is not allowedMySQL 8认证插件埋的坑这个报错算是我见过最迷惑的一个尤其当你用Navicat能连上、写Java却报错时整个人都会是懵的。原因在于MySQL 8默认用的认证插件是caching_sha2_password而不是5.x时代的mysql_native_password。当客户端和服务端之间没有走SSL时这个插件要求客户端从服务端获取RSA公钥来加密密码。而驱动出于安全考虑默认禁止自动获取公钥于是直接报Public Key Retrieval is not allowed。两个方向的解决方案方案一连接URL加参数allowPublicKeyRetrievaltrueuseSSLfalse方案二把数据库用户的认证插件改回去ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES;只提醒一句allowPublicKeyRetrievaltrue本质是允许客户端在非SSL连接下获取服务器公钥这个动作天然存在中间人攻击的风险。如果你所在网络环境不可信老老实实配SSL证书别图省事直接加这个参数。我自己在内网开发机上是加的生产环境绝不这么干。3.4 Communications link failure网络层的完整排查链路Communications link failure后面通常会跟着一串细节比如Connection refused或Connection timed out。前者说明目标主机的端口根本没开后者说明网络包都发不到对方那里。我分享一下自己的排查顺序一条一条过所有步骤都在命令行里完成第一步确认MySQL进程在跑。Linux用ps -ef | grep mysqldWindows看服务列表或tasklist | findstr mysqld。进程不在后面什么都不用查。第二步确认端口在监听。Linux用netstat -tlnp | grep 3306看监听地址是不是只有127.0.0.1。MySQL的默认配置里bind-address127.0.0.1会导致只有本机能连远程一律拒绝。第三步测网络连通性。先ping host确认主机在线再telnet host 3306或nc -vz host 3306测端口。如果telnet连不通说明TCP层就过不去继续往下查。第四步检查防火墙和安全组。Linux上看看iptables -L -n和firewall-cmd --list-all云服务器还要去控制台看安全组规则有没有放行3306端口。这里有个容易忽视的点很多云厂商的安全组默认不放行MySQL端口本地防火墙也开了但安全组没放行一样连不上。第五步检查MySQL配置里是不是开了skip-networking。这个参数直接禁用TCP监听配置了它怎么放行防火墙都没用。这五步走下来基本能找到90%以上的Communications link failure。我还建议在连接URL里加connectTimeout5000避免网络黑洞时线程傻等几十秒。这个参数属于JDBC驱动层面的跟MySQL服务端没关系。3.5 Access denied与ClassNotFoundException两类迷惑性极强的报错Access denied for user rootlocalhost (using password: YES)这个报错很常见但原因并不总是密码错误。梳理成三种情况密码确实打错了命令行先验证用户名/主机组合不匹配。MySQL的用户名实际上是“userhost”这个二元组rootlocalhost和root%是两个完全不同的用户。你在远程连的时候MySQL会找匹配的host记录找不到就拒绝认证插件不匹配。如果你把用户改成mysql_native_password之后没刷新权限或者反过来也可能出现Access denied。遇到这个错先命令行登录排除密码问题再SELECT user, host, plugin FROM mysql.user;查一下用户表看看目标主机的授权记录是否存在。这个思路比盲目重置密码强很多。再说ClassNotFoundException。如果你的报错是ClassNotFoundException: com.mysql.jdbc.Driver其实不是“驱动坏了”而是驱动类的全限定名跟代码里写的不一致。老驱动类名是com.mysql.jdbc.Driver8.x驱动类名是com.mysql.cj.jdbc.Driver。另一个常见原因是jar包根本没部署到位用Maven的话检查scope是不是runtime、是不是被排除掉了用Tomcat部署的话看WEB-INF/lib。还有一种No suitable driver found for jdbc:mysql...的报错通常和ClassNotFoundException同源classpath里没有驱动或者URL前缀写错比如写成了jdbc:mysql少了协议分隔符。检查URL拼写和jar包依赖比改代码更有效。4. 连接只是开始事务、连接池与连接参数调优4.1 JDBC事务为什么默认要关掉AutoCommitJDBC默认是自动提交的也就是每执行一条SQLMySQL就把事务提交了。这在单条SQL场景下没什么问题但在转账、下单这种需要多步操作的业务里就是灾难第一步扣钱成功第二步加钱失败钱就凭空少了。手动控制事务的标准写法Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 执行扣款SQL // 执行入账SQL conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); // 复位避免归还连接池时带着事务状态 conn.close(); }这里踩过的坑是用连接池时如果事务里抛了异常但忘记调rollback连接归还后还残留着未提交事务和锁定资源轻则连接复用时报错重则把数据库锁住。我建议在finally里复位autoCommit并把close也放进来这是连接池场景下的好习惯。关于隔离级别多数项目默认用TRANSACTION_REPEATABLE_READ就够了MySQL的默认就是它。你可以在连接创建后调用conn.setTransactionIsolation()调整但不要随手改隔离级别越高并发性能损失越大。这个属于事务设计范畴回头可以单独写一篇。4.2 连接池生产环境没人直接用DriverManager用DriverManager每次getConnection实际上就是走一遍完整建连流程TCP握手、MySQL握手、认证、建会话。单次耗时从几十毫秒到几百毫秒不定。业务并发一上来光建连接就会把数据库负载拉高。连接池的思路很简单提前建立一批连接反复复用不销毁空闲连接。目前Java世界最推荐的是HikariCP配置简单性能好。我用Spring Boot项目时常用这套配置HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseserverTimezoneAsia/Shanghai); config.setUsername(root); config.setPassword(123456); config.setDriverClassName(com.mysql.cj.jdbc.Driver); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setMaxLifetime(1800000); // 30分钟 config.setConnectionTimeout(30000); HikariDataSource dataSource new HikariDataSource(config);有几个参数容易理解错。MaximumPoolSize不是越大越好连接数超过数据库负载能力反而拖慢整体MaxLifetime一定要小于MySQL的wait_timeout。MySQL默认8小时回收空闲连接如果连接池里的连接生命周期比它还长你拿到的连接其实已经被服务端关闭了执行第一条SQL就会报Connection is not available或者Broken pipe。HikariCP官方建议MaxLifetime设置在25到30分钟比较稳妥。4.3 一张表说清高频连接参数的取舍日常排查连接问题时很大一部分都是URL参数引起的。我把实践中高频使用的参数整理成一张表方便你备查。参数默认值作用实战建议useSSLtrue8.x是否启用TLS加密内网开发false生产公网建议true并配证书serverTimezone无服务端时区MySQL 8必须显式指定一般用Asia/ShanghaicharacterEncodingUTF-8客户端字符集保持utf8不要随便改成gbkconnectTimeout取决于驱动TCP连接超时建议3000~5000ms快速失败socketTimeout0无限socket读写超时有慢SQL时按业务需求设置防止线程挂死rewriteBatchedStatementsfalse批量重写做批量插入时改true性能提升明显allowPublicKeyRetrievalfalse允许获取RSA公钥非SSL且用户是caching_sha2_password时设truecachePrepStmtsfalse缓存预编译语句高频SQL场景建议开启useServerPrepStmtsfalse使用服务端预编译配合cachePrepStmts一起用才有意义插一段个人经验我看到不少人一遇到连接报错就喜欢在URL后面堆参数useSSLfalseuseUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue一串问题看着头疼。其实大部分场景只需要三四个参数。参数不是越多越好每加一个参数都意味着驱动要额外做一件事也可能引入新的兼容问题。调试时先加最必要的那一两个测通了再逐步加。4.4 本地连不上远程MySQL这四关必须逐一过本地代码联调时经常遇到“在服务器本机能连MySQL从外面连不上”的情况。这个问题跟JDBC本身没关系但从JDBC报错倒推时几乎都会归结到下面四关第一关MySQL监听地址。默认bind-address是127.0.0.1必须改成0.0.0.0或内网IP地址然后重启MySQL。这个改动意味着MySQL暴露在更多网络接口上生产环境要配合防火墙一起收紧。第二关防火墙和安全组。Linux先执行firewall-cmd --permanent --add-port3306/tcp再firewall-cmd --reload云服务器还要记得在控制台安全组里放行。这一关经常和第一关一起出事少一个都白搭。第三关数据库用户的host。如果用户是rootlocalhost远程来的请求不会匹配这条记录。最直接的解决方式是新建一个用于远程的应用账号CREATE USER app% IDENTIFIED BY StrongPass123; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO app%; FLUSH PRIVILEGES;%表示任意主机实际生产可以精确到某个IP网段比如10.10.8.%减少暴露面。第四关网络连通性。上面三关都过了还要确认两台机器之间真的能通。telnet server-ip 3306是最快的方法。如果telnet通了但Java还连不上再看连接URL的主机名是不是被DNS解析到了别的IP。这些年我帮同事排查远程连接问题90%以上都出在这四关里而且经常是几关一起出问题。所以建议按顺序过一遍而不是猜来猜去。最后再分享一个小技巧调试连接问题时先把MySQL的general_log打开能看到每个连接的完整握手过程SET GLOBAL general_log ON;排查完再关掉。之前有一次怎么都查不到拒绝原因打开log才发现是服务器在做反向DNS解析导致握手超时这种问题光靠猜是永远猜不出来的。希望这篇从原理到排错、再到进阶的流程能让你以后遇到类似问题时有章可循。
分析法实现IF-ELSE翻译程序：四元式与真假链回填)
