1. 技术选型之前先想清楚Java和MySQL之间的那层桥梁有多宽做Java开发的朋友应该都有这种体会最早学的时候课本上讲的是用JDBC连数据库写一堆try-catch-finally敲着Class.forName注册驱动等进了公司发现项目里全是MyBatis或者Spring Data JPA好像没人再手写JDBC了再过一阵子你会碰到一些老系统里面又混着各种连接池配置、XML里的SQL映射甚至还有直接用JDBC模板的代码。这些其实不是技术迭代把你绕晕了而是数据交互这件事本身分了多个层次。先用最简单的话定义一下Java操作MySQL实现数据交互本质上就是让Java进程和MySQL服务端之间建立一条可靠的通道然后把SQL语句送过去、把结果集拿回来。这个通道可以是一根裸的连接JDBC可以是一根做了复用和管理的连接连接池也可以是一整套帮你把SQL和Java对象互相映射的框架MyBatis。不同方案解决的是不同规模、不同阶段的问题。我个人建议不要一上来就奔着哪个框架最流行去选而是先想清楚自己手上的场景属于哪一类如果只是写个小工具、做一次性的数据迁移、或者学习期间练手JDBC完全够用反而能帮你把整个交互链路看得清清楚楚。如果是正式的Web应用、接口服务哪怕只有几个表也建议直接上连接池MyBatis因为你要面对的并发、连接管理、SQL维护这些问题JDBC裸写会让你痛不欲生。如果团队里有人不太熟练SQL、业务以简单的单表CRUD为主那MyBatis Plus这类封装更彻底的工具能明显提升效率但前提是你要知道它在哪些场景会好心办坏事。这篇文章不打算只停在怎么连上数据库这个层面而是把从环境准备、JDBC核心链路、连接池调优到MyBatis的边界、事务失效这些实战中经常踩的坑串起来讲。你会发现数据交互这四个字真正的分量不在连接数据库那一瞬间而在你连接之后的每一类细节处理上。2. 环境准备里最容易翻车的几个细节都是从报错里总结出来的2.1 驱动包版本和MySQL服务端版本之间的匹配关系很多人第一步就挂在驱动上。MySQL从5.7到8.0认证方式从mysql_native_password变成了caching_sha2_password驱动版本如果太老连接时直接报Unable to load authentication plugin。这个报错我第一次见到时愣了几秒后来才明白驱动不只是负责把SQL送过去那么简单它还要和服务端协商认证方式、字符集、传输协议。版本之间差距太大协商就失败。现在的推荐做法很简单基于MySQL 8.0就用com.mysql:mysql-connector-j:8.x系列。需要注意新版驱动的包名已经变成com.mysql.cj.jdbc.Driver而老代码里常见的com.mysql.jdbc.Driver在8.x里虽然做了兼容但会绕一层弃用逻辑而且有些环境会警告。我建议不管项目多老驱动类名直接用新的两行代码的事能少很多隐性问题。还有一个maven依赖时容易忽略的点某些公司内部私服仓库同步不及时你声明了8.0.33结果拉下来的jar是几个月前的版本。遇到很奇怪的连接握手错误时先看一眼实际jar包的版本号别光看pom里写的版本。2.2 连接串参数里那些加和不加完全不一样的参数链接串是jdbc:mysql://ip:port/dbname?param1value1param2value2这种格式很多人从网上抄一段就开始用我从实际踩坑经验里挑三个值得细说的第一个是useSSL。MySQL 8.0默认开了SSL支持但你如果本地开发环境没有配置证书驱动会试图协商加密连接出现一堆告警甚至连接失败。开发环境建议明确设成useSSLfalse生产环境如果真有安全要求单独配证书而不是靠这个参数默认值碰运气。第二个是serverTimezone。这个参数涉及日期时间类型的时区转换。如果MySQL服务器和Java应用服务器在不同的时区设定下不指定serverTimezone你查出来的DATETIME类型数据经常会比预期差几个小时。我建议统一写serverTimezoneAsia/Shanghai同时把MySQL服务端本身的time_zone也设置为08:00两头一致才不会在夏令时、冬令时这种边界问题上出幺蛾子。第三个是allowPublicKeyRetrievaltrue。这个参数跟caching_sha2_password认证有关。用命令行客户端连接没问题但用JDBC驱动连接时如果服务端用的还是caching_sha2_password且没有提前拿到公钥驱动会拒绝或要求显式允许获取公钥。不加上这个参数你会在连接阶段看到非常晦涩的报错。开发环境加它是省事的生产环境如果你能保证用证书链连接可以不开但大多数人还是因为没开它而卡住。2.3 字符集乱码问题连接层、库表层、Java字符串层三处要对齐乱码是一个老生常谈但永远有人在踩的问题。我见过最典型的场景数据库表是utf8mb4Java代码里字符串也是正常的结果存进去再查出来变成了。原因通常是连接串里少了characterEncodingutf8或者MySQL驱动用了服务端老旧的latin1进行编码转换。正确的做法是三处对齐库和表的字符集是utf8mb4不是utf8utf8在MySQL里不是真正的全量Unicode。连接串里带上characterEncodingutf8注意这里写utf8就能映射到utf8mb4不要写成utf8mb4去填连接参数有些驱动反而认不出来。Java代码层面的字符串本身没问题的话剩下就是传输过程中的编码解码问题。我之前排查过一起乱码问题最后定位到是运维在数据库初始化脚本里对某个字段单独指定了utf8mb3导致那一列存emoji直接失败。字符集这类问题就是它在你不注意的地方作妖排查链路很长所以最好从一开始建表时就统一规范而不是等出了问题再来回溯。3. JDBC的完整链路每一步都值得吃透而不是背下来就完3.1 从Class.forName说起驱动注册的本质是什么很多教材讲JDBC第一步就是Class.forName(com.mysql.cj.jdbc.Driver)然后大家就照着写从来不想为什么。其实这一步的用途是把这个驱动类加载进JVM触发它内部的静态代码块向DriverManager注册一个驱动实例。从JDBC 4.0开始只要你的classpath里有META-INF/services/java.sql.Driver这个文件驱动就会自动被加载注册Class.forName可以省略。但我在实际项目中还是习惯写上因为有的老容器、老中间件会自动扫描驱动而有的不会显式加载能保证行为一致也方便后人一眼看出用的是什么驱动。真正建立连接的核心动作是DriverManager.getConnection(url, username, password)。这一步背后做的事情比想象中多解析URL、选择合适的驱动、和服务端做TCP握手、认证、初始化会话变量。所以一次连接的开销并不小这也是后面要上连接池的根本原因。3.2 Statement、PreparedStatement、CallableStatement三者的边界要分清Statement是基础款就是把SQL字符串原样发给服务端执行。PreparedStatement在它的基础上做了预编译SQL骨架先发给MySQL服务端编译好之后每次执行只传参数。这个设计的收益是双重的防SQL注入、重复执行同样结构SQL时更高效。所以我的原则是凡是带用户输入的SQL一律PreparedStatement没有任何商量余地凡是循环执行同样结构的SQL也一律PreparedStatement性能差异在数据量上来后非常明显。CallableStatement则是用来调用存储过程的。存储过程这个东西现在争议很大我的态度是能用Java代码解决的逻辑就别塞进存储过程里。项目里一旦存储过程变多版本管理、测试、调试成本都会跟着涨。某些极端场景比如复杂报表统计、大批量聚合计算存储过程确实有性能优势但那是数据库专职做数据处理的架构选择问题和Java操作MySQL实现数据交互的通用场景是两回事。看几个热搜词里也有mysql存储过程相关的内容说明很多人确实在用。如果一定要用最好遵守两条存储过程里不要做动态SQL拼接二要注意权限控制别让应用账号拥有创建存储过程的权限只用EXECUTE权限就够了。3.3 ResultSet的遍历技巧和性能陷阱ResultSet表面上是个结果集底层实现里其实是对服务端返回数据的一个游标式访问。默认情况下驱动会把所有结果一次性拉到客户端内存里useCursorFetch相关的行为先不说。数据量小的时候无所谓数据量大了比如一次查了几万行带大字段的记录客户端内存会突然涨一大截。我有一次排查线上OOM发现罪魁祸首就是一个统计接口的SQL查出两万条记录每条带一个几KB的TEXT字段然后Java代码又把这堆数据全塞进了一个List。后来改成流式查询在MySQL驱动里设置useCursorFetchtrue和fetchSize数据从服务端分批拉到客户端内存压力降下来了但代价是查询期间连接会被长时间占用必须谨慎使用。这个故事的结论是结果集不是越大越好也不是越小越好而是要和你能承受的内存连接占用时间之间找到平衡。3.4 资源释放try-with-resources 是底线不是加分项JDBC的老写法里finally块里关闭Connection、Statement、ResultSet顺序还有讲究先关ResultSet再关Statement最后关Connection。如果中间抛了异常某个资源没关连接就不会真正释放后面再用连接池时就会发生连接耗尽之类的事故。Java 7开始有了try-with-resources我现在写JDBC相关代码一律用它语法干净而且关闭顺序是反序的省得自己操心。有一个展开说说很容易被忽视的点Connection的close()方法在普通JDBC里是真正断开连接但如果你用的连接池这个close()其实只是把连接归还给池子。很多新手在连接池环境下写了错误的资源管理代码结果连接被提前归还但ResultSet还没读完后面再读就报Connection is closed。这类问题排查起来非常鬼畜所以我还是那句话不管哪种方式规范的资源释放顺序别乱哪怕有连接池兜底也不能依赖它。4. 连接池的参数不是照着抄的每一个都对应一种故障模式4.1 为什么裸连接撑不住哪怕二十个人的小应用先算一笔账假设你的应用同时在线20人每个接口需要查询3次数据库每次查询建立连接按30ms算加上SQL执行和网络传输一次请求可能要多等100ms以上。更重要的是MySQL服务端对连接数是有上限的默认1515.7及以后是151之前是100而且每建一个连接服务端都要fork一个线程来处理连接数过多时CPU上下文切换会消耗大量资源。裸连接不是不能用而是一次请求期间反复创建连接这件事太浪费了。连接池做的事很简单提前创建一批连接放在池子里谁用完谁还回来用完了不销毁继续给下一个人用。从某种程度上说它像是数据库服务端和Java应用之间的一个排队缓冲区既控制了并发连接数又免掉了频繁建连的开销。4.2 四个核心参数结合我的实际调优经验来理解先说initialSize和minIdle。初始连接数和最小空闲连接数决定了应用刚启动时和低峰期池子里有多少连接。太大会浪费资源太小会在流量突然涌进来时来不及创建连接。我的经验是先设成5~10看监控里连接创建频率决定要不要调。然后是maxActive或者叫maxPoolSize看你用哪个池子。这是池子能同时提供的最大连接数。设太大数据库压力顶不住连接池反而变成了击穿数据库的放大器设太小高峰期会让请求排队等待连接。常见做法是根据数据库的max_connections和应用的预估并发放缩比如数据库允许200连接应用实例有4个那把每个实例的maxActive设成20都不会让连接池成为瓶颈。maxWait则是等待连接的最长时间。这个参数设成-1表示无限等设成0表示立即抛异常。实际生产环境里我一般设3000到5000毫秒超过这个时间就直接让请求失败而不是让线程无限阻塞下去。因为无限等下去最后的结果往往是线程堆积、内存飙升比快速失败还难收拾。这里建议加点料不同连接池的默认值差异很大比如HikariCP的默认maximumPoolSize10而Druid默认是8。换连接池的时候很多人忘了重新审视参数直接用默认值跑结果高并发下一堆连接失败别问我是怎么知道的。4.3 连接池里连接假死的问题validation机制不能省MySQL有个wait_timeout参数默认28800秒8小时意思是超过这段时间没有活动的连接服务端会主动断开。池子里那些长期空闲的连接如果应用侧不知道它们已经被服务端断开了下一次借出去用的时候第一次SQL查询就会报Communications link failure之类的大错而且不是每次都报是隔一段时间抽风一次。解决这个问题的机制是连接有效性检测借出连接前或者拿回连接时执行一条极轻量的查询比如SELECT 1确认连接还活着。各个连接池的机制不完全一样HikariCP默认在连接空闲超过idleTimeout后测试Druid有testWhileIdle和validationQuery的配置组合。我在项目里的习惯是把连接池的空闲检测时间调得比MySQL的wait_timeout短比如服务端设置1800秒那连接池的idleTimeout或timeBetweenEvictionRunsMillis就设成1500秒左右。每次借出连接时做一次轻量探活虽然每次多一点点开销但能避免隔三差五的偶发报错。这个点如果你之前没注意过建议现在就去看一下自己项目里的连接池配置。我见过太多系统平时跑得好好的突然每天凌晨到早上第一波请求前会偶发报错最后查下来都是连接假死问题。5. 从JDBC到MyBatis掌握好谁写SQL的边界才是关键5.1 MyBatis解决的三个核心痛点和它引入的新成本MyBatis在Java和MySQL之间加的这层本质上是做三件事SQL和Java代码分离。XML里写SQLJava里写接口换SQL不用改代码、重新编译这对复杂SQL的维护非常有价值。参数映射和结果映射。Java对象的字段和数据库表的列之间的对应关系不用你每次手动set进去。动态SQL。if、where、foreach这种根据条件拼SQL的能力用JDBC手写的话会写出一堆StringBuilder拼接还容易拼错空格。但如果以为引入MyBatis就万事大吉那就错了。它引入的新成本包括XML和Java接口的映射关系排查成本、动态SQL的复杂规则问题、以及看起来是方法调用其实背后是一整条SQL的心智负担。尤其是团队里有人把复杂的业务逻辑全塞进动态SQL里最后那个XML的if嵌套比Java代码还难读调试起来简直是一场灾难。5.2 手写SQL和MyBatis Plus自动生成SQL什么时候选哪个先明确一点MyBatis Plus的BaseMapper提供的selectById、selectList、insert、updateById这些方法本质上还是帮你生成SQL只是不用你手写XML了。它的方便是肉眼可见的单表CRUD几乎零成本而且配合它根据实体类生成建表SQL的功能这个在后边的实际案例部分会展开说开发效率确实高。问题出在查询条件稍微复杂一点的时候。比如一个订单列表接口要根据状态、时间范围、关键词搜索再按某个字段排序后端还要分页。用Plus的QueryWrapper写虽然能调出来但那串链式调用比XML里的动态SQL也不咋直观。而且一旦多表关联Plus的Wrapper就捉襟见肘了你还是得回退到自定义SQL。我的经验总结就一句话纯单表操作的CRUD用MyBatis Plus的默认方法省时省力一旦涉及多表关联、复杂条件动态拼装、或者对SQL执行计划有精细控制需求必须手写SQL放进XML并用Select注解标记清楚。既要效率又要可控别把两者对立起来。5.3 分页查询的常见误区和排序字段相关的坑分页是Java操作MySQL时绕不开的话题。网上资料很多但真正理解的人不多。MySQL的LIMIT offset, size实现分页很简单但有一个性能边界offset越大扫描的行越多性能越差。比如查第100万页offset10000000, size20MySQL还是会先扫过前1000万行再取20行这个成本非常高。我见过不少系统分页接口在数据量到几十万条之后明显变慢排查一看就是这种深分页问题。优化手段常见的有两种一是用游标式分页即传入上一页最后一条记录的ID用WHERE id ? ORDER BY id DESC LIMIT 20这种方式翻页二是用子查询把主键取出来再join尽量避免大offset。排序字段这块有个隐蔽的坑如果你在SQL里用了ORDER BY一个没有索引的字段随着数据量增长排序会越来越慢甚至出现临时文件和磁盘排序。还有就是在多表JOIN时如果ORDER BY的字段来自多个表MySQL优化器经常会被搞晕执行计划直接给你来个Using filesort。我的处理原则是排序字段要么是主键要么是带索引的列如果业务上必须按非索引列排序那就评估一下数据量级量大了考虑走搜索引擎或缓存。热搜词里频繁出现mysql排序mysql函数大全这类词可见这块确实是高频需求但功能实现容易性能隐患却经常埋着。大家写排序时多想想这个字段有没有索引能省掉后面很多排查时间。6. 事务和数据一致性读到了错误结果往往还不如报错来得痛快6.1 事务默认行为你执行的每条SQL其实都包着一个隐式事务很多人以为只有显式写上BEGIN或START TRANSACTION才有事务其实MySQL默认AUTOCOMMIT1也就是说你每执行一条带写操作的SQL它自己就是一个微型事务要么成功提交要么失败回滚。这个设计在单条SQL的场景下是合理的但一旦你需要多条SQL作为一个整体就必须显式关闭自动提交在Java代码里用connection.setAutoCommit(false)然后commit()或rollback()。Java这边最常见的错误是忘了在finally里根据异常情况回滚或者回滚了但事务没真正关闭。还得额外强调一下用Spring的Transactional时事务边界是由Spring帮你包好的但如果你在方法里自己又拿Connection去操作数据库那这个Connection参与不参与Spring管理的事务取决于你是不是用了DataSourceUtils从当前事务上下文中取连接。搞混了这个就会出现Spring事务没覆盖到自写JDBC操作的情况查数据不一致时让人一头雾水。6.2 事务隔离级别和锁读己之写、脏读、不可重复读、幻读MySQL的存储引擎InnoDB支持四种隔离级别默认是可重复读REPEATABLE READ。它在可重复读下通过MVCC解决了脏读和不可重复读但幻读并没有完全消除严格说在InnoDB的可重复读下通过当前读间隙锁可以防止幻读但快照读下仍可能看似读到新数据。实际业务场景里如果你只是做普通的CRUD默认隔离级别基本够用但如果你要做先查后写这种读改写逻辑就必须警惕并发下的数据错乱。举个例子一个抢购场景先SELECT num FROM stock WHERE id?判断num0后再UPDATE stock SET numnum-1。两个请求同时读到num1都认为可以扣减最后库存变成负数。解决方式很多常见的有SELECT ... FOR UPDATE加锁或者直接UPDATE stock SET numnum-1 WHERE id? AND num0用更新语句本身作为原子判断。这里的关键不是哪个SQL写法更高级而是你要意识到Java代码里的一串操作如果不加锁或不做原子化设计就会在并发下出现覆盖写。注意锁的分类也是一个高频知识点表锁、行锁、间隙锁、意向锁、共享锁、排他锁我在这不展开背概念只提醒一点MySQL的行锁只有在查询条件能命中索引时才真正生效。如果你UPDATE ... WHERE一个没有索引的列InnoDB为了找到目标行很可能把整张表的所有行都锁上这在并发场景下是致命的。写UPDATE、DELETE时一定要检查执行计划看看是不是全表扫描。6.3 批量操作不加事务性能差异能有多大我之前做过一个数据清洗项目需要往一张表里批量插入几十万条数据。一开始用一个for循环每2000条提交一次但每次都自动提交结果跑了快一个小时。后来改成一个事务里执行还是每2000条一个事务总耗时直接降到几分钟。差别在哪每一条INSERT在自动提交模式下都要做一次fsync把日志刷到磁盘和一次事务相关的开销批量放在同一事务里日志和刷盘次数显著减少速度自然立竿见影。但反过来也有教训如果事务过大比如几十万条数据放在一个事务里事务日志、Undo日志会撑得很大而且这个事务持有一堆行锁直到提交阻塞其他会话。我建议的折中方案是单批1000到2000行一个事务既享受批量提交的加速又避免大事务带来的锁和日志问题。这个数字不是绝对的要根据行大小、网络、库压力调整但整体思路就是这样让批量和锁的持续时间保持在一个合理的平衡点。7. 从实体类到建表SQL用一个能提升效率但别依赖过深的技巧收尾我觉得有必要花点篇幅说说热搜词里那个mybatisplus根据java实体类生成创建表的sql语句因为我发现很多同学第一次看到这个功能时特别激动觉得建表可以不用手写了但实际用起来需要知道它的边界在哪。MyBatis Plus确实提供了类似的功能思路你定义好一个Java实体类通过约定好的注解或规则可以生成对应的建表语句甚至能在启动时自动执行建表/更新表结构。这在快速原型开发、演示项目、小团队的早期阶段非常实用。你不需要再手动维护一份建模文档外加一份DDL脚本实体类就是唯一的模型源头。但我的实际体会是这个功能有三个明显的局限它生成的表结构大多是够用级别不是最优级别。索引设计、字段长度、分区策略这些指望靠实体类自动生成是做不到的。一旦表结构要调整它自动ALTER的行为在高危表上风险很大。生产环境如果让应用启动时自动改表结构一旦出问题回滚非常麻烦。团队里如果有DBA或者严格的表结构评审流程这种自动生成的SQL通常过不了评审。所以我的建议是个人项目、课设、快速验证放心用公司正式项目用它来生成初版SQL做参考可以但生产环境的建表脚本还是应该人工Review、加上索引评估再走正规的变更流程。这和我前面对MyBatis Plus整体的态度是一致的封装能提升效率但你不能失去对底层SQL的理解和控制。最后再分享一个我在实际项目里一直坚持的小习惯无论用JDBC还是MyBatis只要是涉及MySQL交互的代码我都会在本地开着general_log跑一遍关键路径看看实际发到服务端的SQL长什么样、参数是怎么拼进去的。这个习惯帮我排查掉了无数个Java代码没问题但数据不对的疑难杂症。你也试试大概率会发现你脑子里以为在执行的SQL和真正在MySQL里跑的SQL有时候差了十万八千里。