/tags/mysql/ Recent content in mysql on Hugo -- gohugo.io en Sun, 26 Apr 2026 10:00:00 +0800 /posts/best-practice-for-liquibase/ Sun, 26 Apr 2026 10:00:00 +0800 /posts/best-practice-for-liquibase/ 本文用一组「问答」拆解 Liquibase（XML 格式）在 Spring Boot 微服务下我更倾向采用的一些实践经验。文中的反例都来自真实可见的代码风格——表名、字段、author 全部脱敏，不指向任何具体项目。每条做法尽量给出官方文档或社区可访问的来源。 一、Schema 应该住在哪个 repo？ Q：为什么我现在不太倾向继续用一个独立的 db-* 仓库（或子模块）单独保存所有 MS 的 schema？ 历史上常见的做法是开一个 database-foo、database-bar 的项目，里面只放 liquibase.properties + 一堆 change-log/*.xml，跑 mvn liquibase:update 完成迁移。问题是： schema 和服务代码不在同一个生命周期里。MS 加了一个 entity_id 字段，PR 在服务 repo；migration 在另一个 repo。两个 PR 难以原子合并，code review 也只能看半边。 CI 触发不一致。服务 repo 的测试不会跑 migration repo 的最新变更；migration repo 的 CI 也很难拿到服务的 entity 类去做 schema-vs-entity 的 sanity check。 不利于 service ownership。微服务的核心原则是 database per service；schema 是这个服务的私有资产，住到外部 repo 等同于把私有资产挪出了边界。 Q：那我现在更倾向怎么放？ 直接放进微服务自己的 repo，使用 Spring Boot 默认约定： /posts/spring-boot-database-best-practices/ Sun, 12 Apr 2026 10:00:00 +0800 /posts/spring-boot-database-best-practices/ 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 2026-04 实践更新 当前主线仓库里，MySQL 领域服务的集成测试基线已经基本统一为 @ServiceConnection；少数仍保留 @DynamicPropertySource 的测试，主要是因为除了数据库容器之外还需要额外挂接自定义属性，而不是数据库接线本身没有迁移完成。 在 Shop Platform 的 15 个服务中，11 个领域服务各自拥有独立的 MySQL 8.4 数据库。Spring Boot 3.5 结合 Spring Data JPA 3.5 提供了比较完善的数据库集成能力，但默认配置未必直接适合当前生产环境。需要额外说明的是：当前仓库已经稳定落地的是 ddl-auto: validate、Flyway 迁移、@ServiceConnection 集成测试，以及部分服务显式关闭 OSIV；像 Hikari 数值和 @EntityGraph 更适合作为“可参考实践”，不应直接写成“仓库现状”。 下面从六个维度整理一下 Spring Boot 3.5 下数据库实践里更常遇到的点。 HikariCP 连接池调优 为什么需要调优 Spring Boot 默认的 HikariCP 配置是 maximum-pool-size: 10。这个值适合当起点，但对容器化环境来说，既可能偏小，也可能偏大。 一个更稳妥的压测起点 spring: datasource: hikari: maximum-pool-size: 10 # 先作为压测起点 minimum-idle: 2 # 最小空闲连接 connection-timeout: 5000 # 获取连接超时（ms） idle-timeout: 300000 # 空闲连接超时（5 分钟） max-lifetime: 1200000 # 连接最大生命周期（20 分钟） 怎么确定 maximum-pool-size HikariCP 作者 Brett Wooldridge 的公式：