1. 项目背景与整体思路1.1 看似基础的Spring Boot数据库操作为什么值得单开一篇前两天有个朋友问我他说自己在网上跟着视频抄了一个Spring Boot项目CRUD都能跑通但一旦让他不看教程自己重写一遍脑子就一片空白。为什么因为数据库操作这段从来不是“抄几个注解”那么简单它牵扯到配置文件、连接池、事务、日志、权限、表结构设计等一长串东西。你漏掉任何一个环节跑起来就像拆盲盒——有时候运气好能出数据有时候直接白屏还有时候接口能通但数据死活写不进去。Spring Boot的数据库操作本质上是把“Java应用连上数据库并读写数据”这一整套链路理顺。我在这篇实战记录里不打算只贴一段能跑的代码就收工我想把那些文档里不会明说的细节一起讲透Navicat里怎么给账号申请只读权限、application.yml里每个参数到底管什么、为什么你改了数据库连接却还在用旧连接、以及从“单表CRUD”走到“企业级系统”会遇到哪些分水岭。这样你以后不管做“校园讲座预约系统”还是“企业办公用品管理系统”都能借此把根基打牢。适合谁来读两类人。第一类是刚学会Spring Boot、想系统补上数据库操作这块短板的同学第二类是已经在写业务接口、但经常在数据源配置、事务控制、日志排查上卡壳的初级开发。我尽量用大白话讲清楚原理再给你可以直接抄走的配置和代码这样不同基础的人都能有收获。1.2 这套实战做出来是什么样为了让这篇内容不飘在空中我选了一个非常常见的业务场景地址簿管理。为什么选它因为它把数据库操作最核心的增删改查全都覆盖了而且表结构足够简单不需要额外引入复杂关联关系正好可以用来讲清楚Spring Boot操作数据库的最小闭环。整体目标是这样本地建一张联系人表用Navicat把数据库账号权限分好Spring Boot项目通过配置文件连上数据库然后对外提供几个HTTP接口分别实现新增联系人、查询联系人列表、修改联系人和删除联系人。跑通这个闭环以后我们再顺手讨论一下多表设计、缓存、消息推送和权限控制的扩展方向。你会发现校园讲座预约系统、餐饮SaaS、办公用品管理这类项目本质上都是在这个骨架上面不断叠功能。2. 数据库准备与 Navicat 那点事2.1 建库建表前的几个决策很多人一上来就打开Navicat新建数据库这没错但我想先提醒你三件事。第一数据库名和表名最好统一用小写加下划线比如address_book不要用大写驼峰。这不是纯强迫症Linux服务器上的MySQL对大小写敏感你本地用大写没问题一旦部署到服务器SQL语句里大小写稍微不一致就直接报错“Table doesnt exist”。第二表结构里的注释尽量写清楚因为后面写实体类时候字段注释能帮你减少大量理解成本。第三字符集直接选utf8mb4别再用老旧的utf8。我见过太多项目因为utf8mb4和utf8的区别最后存emoji或者生僻字时出现乱码排查半天还得改表结构。建表语句我给你一个可以直接复制的版本CREATE TABLE address_book ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, name VARCHAR(64) NOT NULL COMMENT 联系人姓名, phone VARCHAR(20) NOT NULL COMMENT 手机号, address VARCHAR(255) DEFAULT NULL COMMENT 地址, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT地址簿表;这里有两个设计细节值得展开。第一个是主键用BIGINT自增还是用雪花ID取决于你的业务规模。单机小项目自增完全够用但如果是分布式多实例写入同一个表自增ID很容易撞车这时就得换成雪花算法生成的全局唯一ID。第二个是时间字段我习惯让数据库层自动维护create_time和update_time而不是让Java代码手动设值。原因很简单防止不同服务器之间时钟不一致也省得每个接口都重复写一遍时间赋值逻辑。你在代码里只要管业务字段就行了。2.2 Navicat 操作怎么创建只读权限账号数据库一般不建议所有人共用同一个高权限账号。开发环境可以图省事直接用root但一旦涉及到测试环境、线上环境或者需要把数据库暴露给同事、外包、数据分析师就必须做权限隔离。我先把Navicat里创建只读账号的完整步骤理一遍。打开Navicat连接到你的数据库服务器然后依次点击“用户”或“用户权限”菜单。新建一个用户名字比如叫reader主机选择localhost或者%密码单独设置。关键在“服务器权限”或“权限”选项卡里只勾选SELECT其他增删改权限一概不勾。如果只允许读某一个库就在“对象权限”里选择具体的数据库和表把SELECT勾上INSERT、UPDATE、DELETE、ALTER、DROP这些全都留空。我实操的时候还会多做一步给只读账号单独设置最大连接数或者干脆限制来源IP。这样就算有人拿这个账号去拖数据也不会因为连接数占满影响正常的读写服务。顺便说一句只读权限不是线上才需要考虑的事。哪怕是本地开发我建议你至少建两个账号一个admin管结构一个app账号负责日常读写。这样你在执行项目交接的时候不至于把改表结构的权限随手丢给所有人。还有一个容易忽略的操作如果你改了用户的权限Navicat有时候不会立刻生效。你需要在“用户权限”界面点刷新权限或者执行FLUSH PRIVILEGES。我遇到过一个很诡异的现象权限明明已经去掉了但通过旧连接还是能删数据后来发现就是连接池里的旧连接没有释放MySQL在连接建立时读取了一次权限之后这个连接就一直持有旧权限直到断开。这个问题放到Spring Boot里同样存在等下讲数据源配置时你会再次遇到它。2.3 为什么单独维护只读账号不只是为了安全聊到这里肯定有人觉得“我一人一个库要什么只读账号”。但实际项目里数据库账号往往不是一个人说了算。甲方要报表、运营要导出数据、测试要造数据这些人不一定都懂SQL语法万一一个手滑执行了DELETE不带WHERE后果你可能要加班修复。只读账号相当于给他们开了个“只许看、不许碰”的窗口这不光防外部误操作也是防内部误操作。再往前想一步只读账号还能用来做数据源的读写分离。很多中型项目会把读操作和写操作分流到不同数据库节点主库负责增删改从库负责查询。Spring Boot里可以配置多个数据源读库连接正好用只读账号写库连接用读写账号。这样你在架构选型上就提前留好了余地不至于以后流量上来了再大改代码。这个思路你在做基于Spring Boot的校园讲座预约系统这类高并发读场景时特别有用讲座列表、座位余量查询都是读多写少很适合把只读实例独立出来扛流量。3. Spring Boot 端配置别看轻这几行 yml3.1 依赖引入与 application.yml 配置数据库准备好了接着就是Spring Boot项目里引入依赖。最常用的是Spring Data JPA和MyBatis两类我这边先用Spring Data JPA做演示因为它的设计哲学是“让开发者专注于实体和仓库接口SQL由框架生成”。如果你偏好手写SQL可以把spring-boot-starter-data-jpa换成mybatis-spring-boot-starter核心思路完全不变只是数据库访问层写起来风格不同。我见过太多新手在依赖上踩坑。有一个非常典型的坑网上教程写的是spring-boot-starter-parent版本2.7但你的JDK是21启动直接报错“Unsupported class file major version”。版本对应关系一定要提前确认Spring Boot 2.x最高支持到JDK 17Spring Boot 3.x要求JDK 17以上而JDK 21搭配Spring Boot 3.2以上体验最好。如果你非要配Spring Boot 3.5那直接上JDK 21配合虚拟线程来处理高并发任务会非常舒服。这一点我在后面第7节展开讲。application.yml里最核心的配置段如下spring: datasource: url: jdbc:mysql://localhost:3306/address_book?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: app_user password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000 idle-timeout: 600000 jpa: hibernate: ddl-auto: update show-sql: true properties: hibernate: format_sql: true每个参数背后都有讲究。url里的serverTimezone必须设置不然你连数据库时会相差8小时或者直接报时区错误。allowPublicKeyRetrievaltrue是针对MySQL 8.0的不加上去用默认账号密码登录时偶尔会报Public Key Retrieval is not allowed。driver-class-name在Spring Boot 2.x以后其实可以省略但写上能避免某些IDE环境自动检测出错。owner concern不加这些本地Windows能跑一到Docker或云服务器就翻车。3.2 连接池参数往往是性能问题的第一道关口Spring Boot 2.x之后默认的连接池是HikariCP这个连接池的特点是快、轻量、稳定。但你千万别觉得默认值永远适合你。我这里专门讲一下maximum-pool-size这个参数它代表数据库连接池里最多同时存在多少个物理连接。很多人一碰到并发高第一反应是把这个值调到100、200结果数据库连接数被打爆反而更慢。为什么因为每条连接背后都是数据库进程里的一个线程连接过多会造成上下文切换开销陡增事务锁竞争也更激烈。比较合理的做法是先用公式估算单条连接能处理的QPS大概在几百到一千你预估系统峰值QPS是2000事务平均耗时20毫秒那连接数大约等于峰值QPS × 平均事务耗时秒数也就是2000×0.0240。然后再打一个折扣留出Buffer一般取30到50。如果想更精确就压测后根据监控慢慢调不要一步登天。还有两个容易被忽略的参数。connection-timeout代表从连接池获取连接的超时时间如果业务高峰期抢不到连接等太久会让线程越积越多idle-timeout代表空闲连接存活时间空闲太久会被回收这个值不要低于数据库自身的wait_timeout否则会出现连接没断但数据库已经把它杀了下次使用时报错。这类问题排查起来特别隐蔽因为不是每次都报错而是跑一段时间后随机报错。日志里如果出现“Connection is not available, request timed out after 30000ms”无一例外都是连接池配置和数据库参数不匹配闹的。3.3 多环境配置不要把密码写在同一个文件里真实项目里开发环境、测试环境、生产环境的数据库地址和账号密码完全不同。要是你只在application.yml里写一套配置发布时手动改迟早会出事故。Spring Boot原生支持多Profile配置把公共配置放在application.yml把不同环境的差异放到application-dev.yml、application-test.yml、application-prod.yml里启动时用参数指定java -jar demo.jar --spring.profiles.activeprod还推荐使用环境变量把敏感信息注入进去而不是把生产密码直接写进代码仓库。比如配置里写成spring: datasource: password: ${DB_PASSWORD}这样部署到服务器时只需要在系统的环境变量里设置DB_PASSWORD即可。密码不进Git、不截图发到群里、不写进博客这是我在实际项目里踩过坑之后养成的底线习惯。4. 写一个能跑的地址簿管理接口4.1 快速创建 Spring Boot 项目并跑通第一个接口先说怎么快速创建一个Spring Boot项目。如果你不想在IDE里一步步点Next最简单的办法是直接用Spring Initializr生成在浏览器打开start.spring.io填入项目名选择Java版本、Spring Boot版本依赖那一栏勾选Spring Web、Spring Data JPA、MySQL Driver、Validation。生成之后下载解压用IDE导入然后就能得到最基础的可启动工程。这一步是很多教程最轻视的“第1关”但恰恰是第一个Spring Boot程序最容易卡住的地方依赖没下载全、Maven仓库源太慢、Java版本不匹配。第一次运行Spring Boot程序看到控制台出现“Started Application in X seconds”才算真正过关。如果你在这一步遇到端口被占用可以在application.yml里改server.port如果启动报错“Failed to configure a DataSource”说明你还没在配置里给数据源填完整或者依赖里没有对应的数据库驱动。这些报错其实都是组件之间配合出现了问题一步步拆开看并不可怕。第一个接口不要一上来就写CRUD。先写一个最简单的GET接口返回字符串或者返回当前时间目的不是业务价值而是验证整个Web请求链路通不通。我的代码习惯是先建一个包叫controller里面放一个HealthController注明这是健康检查接口将来部署了探活也能用上。RestController RequestMapping(/api/health) public class HealthController { GetMapping public ResultString health() { return Result.success(ok); } }跑通以后你会对“请求从哪里进来、controller怎么接住、响应怎么回去”有个直观感受再来写数据库相关接口就顺了。4.2 实体类、Repository 和 Service一张表对接三层代码数据库表准备好以后第一件事是写实体类。实体类说白了就是Java里和表结构一一对应的一个POJO。字段名、类型、注解都要对得上否则框架会在启动时或者运行时给你报一堆映射错误。Entity Table(name address_book) public class AddressBook { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(nullable false, length 64) private String name; Column(nullable false, length 20) private String phone; private String address; private LocalDateTime createTime; private LocalDateTime updateTime; // getter / setter 省略 }写完实体类后写Repository接口。Spring Data JPA的Repository很有意思它允许你通过方法名直接推导SQL。比如你要查所有联系人就在接口里声明findAll()这是父接口自带的方法你要按姓名查询写findByName(String name)框架会自动生成类似where name ?的查询。它还有一个大招支持在方法上写JPQL或者原生SQL适合复杂查询。Service层的作用是承载业务逻辑。我强烈建议不要在Controller里直接注入Repository因为Controller的职责应该只是接收参数、调用业务服务、返回响应。如果业务逻辑越堆越多Controller会变得又臭又长以后想加一个事务注解或者加一个权限判断都会牵一发动全身。分层不是为了好看是为了降低维护成本。你去看那些基于Spring Boot的企业办公用品管理系统代码结构再烂基本也都会分出controller、service、repository这几层。4.3 Controller 里的增删改查与参数校验地址簿的接口我设计成这样GET /api/address/list查询全部联系人GET /api/address/{id}按ID查询单条POST /api/address新增联系人PUT /api/address/{id}修改联系人DELETE /api/address/{id}删除联系人新增接口的代码长这样PostMapping public ResultLong add(Valid RequestBody AddressBookRequest request) { AddressBook book new AddressBook(); book.setName(request.getName()); book.setPhone(request.getPhone()); book.setAddress(request.getAddress()); addressBookService.save(book); return Result.success(book.getId()); }这里有一个关键点我特意标注了Valid。参数校验必须做在Controller入口而不是等到进数据库才报错。因为数据库层的异常很粗糙用户看到的是“字段不能为空”的英文提示体验很差。更专业的做法是定义一个请求DTO字段上加NotBlank、Pattern这样的校验注解让Spring在进入Service之前就把非法参数拦下来。手机号校验就是典型场景我用这样一个正则Pattern(regexp ^1[3-9]\\d{9}$, message 手机号格式不正确) private String phone;为什么手机号校验这么重要因为地址簿的数据后续可能会被营销系统、通知系统拿去用一个格式错误的手机号会导致短信发送失败或者统计报表对不上。你宁可接口调用方多传几次正确参数也不要把脏数据沉淀到库里。修改接口和删除接口也都有讲究。修改时先把ID对应的记录查出来如果查不到就抛业务异常而不是直接调save方法覆盖数据删除时同理先判断存在不存在删除一个不存在的ID返回成功会误导调用方。我自己习惯把这类判断封装在Service里并抛出一个自定义异常由全局异常处理器统一转成JSON返回这样代码里就不会到处散落if else处理。5. 常见坑数据库操作报错的排查实录5.1 驱动类、时区和SSL三个启动期炸弹数据库操作最常见的报错很多都发生在项目启动阶段。第一个是“Cannot load driver class: com.mysql.jdbc.Driver”这个基本是因为你依赖里压根没引入MySQL驱动或者引入了旧的驱动类名。MySQL 8之后驱动类名是com.mysql.cj.jdbc.Driver不要再用旧的那个mysql.jdbc.Driver。第二个报错是“The server time zone value GMT08:00 is unrecognized”这是url里没设置serverTimezone导致的。第三个是一些安全连接相关的问题useSSLfalse能解决本地连不上allowPublicKeyRetrievaltrue能解决MySQL 8的认证方式问题。这三个报错经常连着一起出现所以新手常常怀疑自己是不是装错了数据库。其实本质都是客户端和MySQL服务器之间的握手参数没协商好。我处理这类问题的实操顺序是先打印url确认没乱码再看driver类名对不对最后检查MySQL服务端版本。这三个排查步骤能覆盖90%的启动期连接问题。5.2 Bean 注入失败和事务不生效最容易让人心态崩溃Spring Boot里写数据库操作离不开依赖注入。把Repository注入到Service里或者把Service注入到Controller里都是家常便饭。但有时候你会遇到“Field xxx in XxxService required a bean of type xxx that could not be found”的报错。第一次看到这个报错第一反应是到处加注解其实通常的原因就几个类没放在Spring能扫描到的包路径下、忘记加Repository或Service、或者依赖冲突导致组件没有注册成功。关于Bean的注入控制我还要多说一句。Spring Boot支持字段注入、构造器注入和Setter注入但我在实际维护项目中更推荐构造器注入。为什么因为构造器注入能把依赖关系在对象创建时一次性确定下来字段注入写起来方便但很容易绕开对依赖的显式控制尤其在写单元测试时需要额外的反射处理。你在网上会看到很多老项目用Autowired字段注入能用但如果要长期维护建议慢慢迁到构造器注入。事务不生效这个问题更隐蔽。你给Service方法加了Transactional执行出错时数据应该回滚结果发现库里还是多了脏数据。最常见的元凶是自调用同一个类里的方法A调用方法BB上的Transactional注解不生效因为Spring事务是通过动态代理实现的自调用绕过了代理对象事务切面根本没机会介入。解决办法是把事务方法放到另一个Service类里或者通过AopContext.currentProxy()获得代理对象主动调用。另一种情况是方法不是public的Transactional只能作用于public方法因为代理机制的限制。还有一种情况是异常被内部catch住了事务感知不到异常自然不回滚。所谓“事务”不是一句注解那么轻巧它背后是代理、异常传播和事务边界三个概念同时配合。5.3 通过日志定位慢 SQL 和数据问题Spring Boot里最常见的日志输出方式就是控制台加文件。配置文件中可以这么设置logging: level: root: info org.hibernate.SQL: debug org.hibernate.type.descriptor.sql.BasicBinder: trace这样设置之后你会在日志里看到打印出来的SQL语句和参数值。为什么这个对数据库排查很重要因为很多业务问题本质是SQL没按预期执行。比如你明明只想查5条数据框架却把全表数据load进内存再过滤这时候看日志能立刻发现问题。日志不是给人凭空观察用的它是定位慢查询、核对字段映射、捕捉异常堆栈的核心工具。在实际项目里我还会引入p6spy或者直接开启MySQL的慢查询日志把所有执行时间超过1秒的SQL单独记录。抓到了慢SQL再用EXPLAIN看执行计划检查是否命中索引。这些习惯配合Spring Boot的日志体系能让你在预警系统报警之前就发现大多数数据库问题。6. 再往前走一步从单库单表到企业级功能6.1 多表设计的典型场景校园讲座预约系统地址簿只是一个最小闭环真实项目里的数据库操作远远不止单表增删改查。我拿热搜里出现的校园讲座预约系统来举例这个系统至少涉及五张表讲座表、用户表、预约表、会场表、签到记录表。预约表引用讲座ID和用户ID最关键的业务规则是“同一讲座同一用户只能预约一次”这就要在预约表上建联合唯一索引或者在插入前先查询校验。更麻烦的是并发预约问题。两个用户同时抢同一个讲座的最后一个名额如果代码里是先查再插那两次查询都发现还有名额然后都插入成功座位超卖。这里一定要用数据库层面的约束或者事务配合锁来解决。最稳妥的方式是给预约表加联合唯一索引或者用SELECT FOR UPDATE锁定讲座记录让同一时刻只有一个事务能修改余量。这类问题在单表CRUD里完全不会遇到但一旦做成真实系统就会立刻冒出来。6.2 WebSocket 推送、Caffeine 缓存和 MinIO 文件服务把基础CRUD打通之后很多人会开始追求“高并发”“实时性”“文件存储”热搜词里正好也出现Spring Boot集成WebSocket yml配置、Caffeine缓存和MinIO。我分开说一下它们在数据库操作场景里的作用。讲座座位或订单状态变化后客户端希望实时收到通知这就要用WebSocket。Spring Boot里配置WebSocket不算复杂但容易在yml配置和握手拦截器上翻车。你可以在application.yml里定义端点路径、允许的跨域来源然后在配置类里注册WebSocket处理器。一个常见的坑是Spring Boot 3和javax的版本兼容问题Spring Boot 3里大量包名从javax改成了jakarta如果导入的是老包的WsConfigurer就会抛NoClassDefFoundError。缓存层我用Caffeine它的定位是本地缓存比Redis轻量适合放变动不频繁的数据比如讲座基础信息、系统字典。Spring Boot集成Caffeine也很简单先引入依赖然后在配置类里注册CacheManager接着在Service方法上加Cacheable注解。它的意义不只是“快”更重要的是减轻数据库压力。如果每次都直接查DB数据库迟早成为瓶颈。MinIO是这几年很火的对象存储方案适合存头像、讲座海报、办公用品管理系统的Excel模板。Spring Boot集成MinIO主要靠依赖io.minio:minio和配置类里手动构建MinioClient。注意对象存储的URL签名会有时效数据库里存的一般是文件对象名而不是临时下载URL不然过期之后前端就拿不到文件了。6.3 权限控制、多租户与数据隔离企业办公用品管理系统这类项目里数据库操作还有一个绕不开的主题权限控制。不是说用户登录了就能看所有数据而是不同部门、不同角色能看到的数据范围不一样。控制方式可以在SQL层加条件也可以在代码层过滤。对于中小系统我推荐在Repository方法中显式拼接部门ID条件或者使用Spring Security配合PreAuthorize注解控制接口级权限。Spring Security的配置在Spring Boot 3里变化比较大。以前WebSecurityConfigurerAdapter还在Spring Boot 3之后主流的写法是直接定义SecurityFilterChain这个Bean把各种请求的放行规则、登录页、csrf开关都写在一个方法里。这部分建议单独花时间看官方文档因为网上很多旧教程已经对不上新版本了。权限和数据隔离如果做不好往往比SQL性能问题更致命轻则越权访问重则数据泄露。多租户则是另一层问题。餐饮SaaS这种一个数据库服务很多家商户的系统每个商户的数据必须隔离。常见做法有独立数据库、独立表、共享表加租户ID三种方案。共享表加租户ID最省资源但必须确保所有增删改查都带上tenant_id过滤条件漏掉一个查询就会把商户A的数据展示给商户B。这种问题靠测试很难全发现最好的办法是在框架层面做强制拦截。7. 新版本新特性Spring Boot 3.5、JDK 21 和虚拟线程7.1 为什么要关注版本组合热搜里出现“Java21 Spring Boot 3.5启用虚拟线程”这其实代表了当前新项目选型的一个重要方向。JDK 21引入了虚拟线程目的就是解决“高并发下的线程阻塞”问题。以前每个请求占用一个操作系统线程线程数量一大上下文切换开销非常可观。虚拟线程是JVM管理的轻量级线程数量可以开到几十万而不压垮系统特别适合大量I/O等待的场景比如数据库查询、外部接口调用。但虚拟线程不是银弹。它只适合I/O密集型任务不适合CPU密集型计算。如果你的业务里全是复杂计算、图像处理虚拟线程的优势就发挥不出来。另外虚拟线程搭配传统的某些连接池或同步锁时会有坑比如在synchronized块里做数据库操作不一定会释放调度线程。所以在Spring Boot 3.5里启用虚拟线程我建议先在非核心非关键链路上做灰度验证确认链路稳定再逐步切过去。7.2 迁移到 Spring Boot 3 时数据库相关代码要注意什么如果你手上有老项目想从Spring Boot 2.x迁到3.x数据库相关的迁移点主要集中在几个地方javax命名空间改成jakarta、部分配置属性名发生了调整、Spring Security的配置方式翻新、Jetty/Tomcat等容器的默认行为也有变化。拿javax.persistence改成jakarta.persistence来说你的实体类里所有Entity、Table导入都需要替换批量替换倒不难就怕有的依赖还是老版本编译时各种矛盾。配置属性上最典型的变化是spring.datasource.*整体保持兼容但很多内嵌容器、监控端点、分页插件的属性名前缀变了。迁移时别存侥幸心态最好把启动日志里所有deprecated配置项逐个处理否则线上环境时不时出现奇怪行为。实操层面我会建议先用Spring Boot Migrator这类工具扫描再做一轮手动的配置核对最后用一个覆盖主要读写链路的自动化测试把迁移后的项目跑一遍。8. 踩坑记录与个人体会8.1 我自己经历过的最诡异的数据库连环坑这个东西我要单独分享因为它综合了前面讲的很多知识点而且特别容易复现。之前有一个系统测试环境一切正常一到生产环境就出现偶发性的“连接被关闭”。排查过程非常折磨人前后查了三天。最后发现是数据库服务器的wait_timeout只有8小时而连接池的空闲连接没及时释放超过8小时之后数据库那侧就把空闲连接断掉了。连接池里的连接却不知道还给业务线程用于是第一次执行SQL时直接报错。解决办法有两个层次。第一个层次是把HikariCP的max-lifetime设置得比数据库wait_timeout短一点比如数据库8小时连接池设5小时。第二个层次是打开连接池的连接测试HikariCP里有一个connection-test-query虽然默认有但一定要确认配置没被覆盖掉。经过这次之后我在任何项目的配置检查清单里都固定加一条核对数据库wait_timeout和连接池的各项超时时间。这一条写进我的个人日志里省掉未来可能的一大堆麻烦。8.2 最后的经验命名、分层和变更管理比手写代码更重要数据库操作写得多了你会发现最花时间的地方不是写SQL而是命名、分层和变更管理三件事。命名要是乱来比如表叫t_user_info字段叫u_name维护半年后你想重构都无从下手。分层要是乱来所有逻辑都堆在Controller里事务边界根本画不出来并发问题只会越来越多。变更管理要是乱来开发环境改个字段测试环境还拿旧SQL造数据部署上去就全线报错。我建议你在项目初期就定一套固定规范表名用下划线命名、Java实体用小写驼峰、Repository方法名遵循统一前缀、Service层严格按事务边界拆分、数据库变更脚本统一收进resources/db/migration目录而不是直接在Navicat里手动执行。规范往往看起来“麻烦”但它能让你在项目进入第四周、第四个月之后依然不用靠回忆来维护代码。8.3 后续可以怎么继续扩展地址簿管理系统做到这里已经具备从“能用”走向“好用”的基础了。你可以继续加索引优化查询性能也可以引入Redis做缓存热点联系人还可以给接口补充分页查询和批量导入功能。如果你正在做毕业设计比如基于Spring Boot的校园讲座预约系统你就可以在这个骨架上把讲座管理、预约、签到、消息通知、数据统计逐个填进去再配合本文讲到的只读账号、连接池调优、日志排查方案整个系统的技术深度会立刻和其他人拉开差距。记住一个原则数据库操作从来不只是CRUD它是数据一致性、性能、安全性和可维护性的共同载体。多写几遍多想几层你就从“能跑”走到了“能扛”。