好，咱们今天聊聊 Spring Boot 配置数据库这事儿。说实话，每次新项目启动，我第一件事就是打开 ，把数据库连接写进去。看着简单，但坑真不少。记得有次帮朋友排查线上问题，业务逻辑跑得挺欢，结果第二天早上数据全丢了——一查，原来他把数据库配置里的 URL 写成了 ，测试环境没问题，部署到生产环境就傻眼了。这种事儿，干我们这行的，谁没遇过一两次？所以今天咱们就掰扯掰扯，怎么把这活儿干得又稳又清爽。
配置数据库，核心就是那几行参数：、、、。但很多人图省事，直接把这些东西硬编码在 里。要是本地开发还好说，一旦要部署到不同环境（比如测试、预发布、生产），每改一次就得重新打包，简直要命。我见过最离谱的，有哥们儿在代码里写死了数据库密码，结果项目上线后密码泄露，被黑客拖了库。所以第一原则：敏感信息别硬编码，用环境变量或配置中心来管理。Spring Boot 支持 这种占位符，你可以在启动命令里传参，或者配合 Docker 的 变量，既安全又灵活。
再说说多数据源的场景。很多项目需要连接两个数据库——一个主库写业务数据，一个从库做报表查询。Spring Boot 默认只配一个 ，要想支持多个，就得手动配置。这时候别慌，核心思路是定义两个 Bean，用 标注主库，再给每个 Bean 绑定不同的配置前缀。比如主库用 ，从库用 。但有个坑：事务管理也得分开配置，不然在同一个服务里同时操作两个库时，事务边界会乱。我以前踩过这个雷，后来学乖了，用 指定 ，或者干脆使用分布式事务框架（如 Seata），虽然重了点，但省心。
连接池的选择也是个技术活儿。Spring Boot 默认用 HikariCP，这玩意儿性能确实好，号称“史上最快连接池”。但很多人只用了默认配置，结果高并发时频繁报“连接超时”。其实 HikariCP 的参数很讲究： 别设太大，一般 10 到 20 就够，设太大反而浪费资源； 设成 5 左右，保证有常驻连接； 别超过 30 秒，不然用户等得心焦。我有个项目，一开始默认配置，压测到 500 并发就挂了，后来把 设成 1800 秒（30 分钟），加了 ，性能直接翻倍。记住，连接池不是越大越好，得根据业务流量调优。
说到生产环境，数据库连接出问题是最常见的。比如网络波动导致连接断开，或者数据库重启后连接池里的连接失效。Spring Boot 虽然有自动重连机制，但默认只会尝试一次，失败就抛异常。这时可以加 （或 ）进行检测。更靠谱的方案是集成健康检查接口，例如用 Spring Actuator 的 端点监控数据库状态。我有个教训：有次数据库做主从切换，业务代码没感知，结果半小时后才发现数据写不进去，损失惨重。后来加了重试机制，配合 Ribbon 的故障转移，才算踏实。
配置文件的组织也有门道。有些人把所有环境配置塞进一个 ，用注释区分，结果每次部署都得手动改。推荐的做法是使用 Profile：、，然后在启动时加 。这样不同环境互不干扰。但公共配置要放在 里，比如 、 等。还有个技巧：用 指定外部配置文件目录，例如挂载一个 目录，这样运维同事不用改代码就能调整参数。我见过一个团队把数据库密码写在 Git 仓库里，结果被实习生不小心 push 到公开仓库，场面尴尬得脚趾都抠地。
聊聊数据库版本管理。很多项目用 Flyway 或 Liquibase 管理 Schema，但与 Spring Boot 集成时容易出问题。比如 Flyway 默认会检查迁移脚本的校验和，如果改了已执行过的脚本，启动就会报错。解决办法是别动历史脚本，只新增新的版本号。还有个坑：多数据源时，每个数据源需要单独配置 Flyway 实例。我有个项目，主库和从库的结构不同，结果 Flyway 在主库执行了从库的脚本，把表结构搞乱了。后来学聪明了，用 注解区分，或者把迁移脚本按数据库分目录，例如 、，清晰又安全。
配置数据库这事儿，看着简单，但细节决定成败。从参数调优到安全防护，从多数据源到版本管理，每一步都得想清楚。别等到线上出问题才后悔图省事。记住，好的配置不是写出来就完事，而是能随着业务变化灵活调整，扛得住流量峰值，防得住意外故障。下次打开 时，不妨多问自己一句：这配置，真的够稳吗？
