## 01、痛点

凌晨两点，订单表突然卡死，几十个连接在等待元数据锁，业务完全不可用。排查发现，发布时 Hibernate 自动改表，给一张两千万行的表加索引，还顺手调整了另一个字段类型。我是老李，经历过这种场面。开发环境里 ddl-auto=update 确实方便，实体类加个字段，重启就自动加列；改个注解，索引也自动修。但这种便利一旦带到生产，就变成了事故。

现在为什么还要讲这件事？因为微服务让数据库连接更多，快速迭代让 Schema 变更更频繁，容器化发布让应用启动更随意。如果不把生产数据库的结构变更像代码一样管起来，迟早会踩大坑。今天我们就来聊聊，怎么把生产环境的 Hibernate 自动改表关掉，用 Flyway 管好每一次数据库结构变化。

## 02、是什么

Hibernate 的 ddl-auto 有几个常用值。none 表示什么都不做，validate 只校验 Entity 映射和数据库表结构是否一致，update 会根据 Entity 映射自动生成 alter 语句修改表结构，create 每次启动先删再建，create-drop 在应用关闭时删表。开发阶段用 update 很顺手，但它本质上是 ORM 的便捷功能，不是数据库变更管理工具。

Flyway 和 Liquibase 是专门的数据库迁移工具。核心是版本化迁移：每个变更脚本有一个唯一版本号，按顺序执行，执行过的版本记录在历史表里，不会重复执行。Versioned Migration 就是这种带版本号的脚本，比如 V1__create_customer.sql、V2__add_customer_status.sql。Baseline 是给存量数据库打标记，告诉工具当前库已经处于某个版本，后续迁移从那个版本开始。

数据库版本演进，就是通过一连串有顺序、有记录、可评审的迁移脚本，把库结构从历史状态安全地推到目标状态。每次变更都留下痕迹，不会凭空发生。

## 03、为什么

为什么 Entity 改了不代表生产表就应该自动跟着改？因为 Entity 描述的是目标模型，是应用当前期望的结构；Migration 描述的是数据库如何从历史状态安全走到目标状态。这两件事完全不是一回事。

Entity 回答的是“最终长什么样”，它不会关心这个过程是否会导致锁表、是否会丢数据、是否需要回滚、是否要先迁移数据再改结构。自动改表只是根据最终结构推断差异，然后立刻执行 alter。比如 Entity 加了一个非空字段，自动改表可能直接加一个没有默认值的列，导致现有数据全部报错；或者改一个字段类型，直接触发整表复制，锁表几分钟。

生产环境要的是可预测、可审查、可重复。每一步变更都要有脚本，经过评审，知道它到底做了什么，影响哪些行，怎么回滚。这些是 Entity 映射不可能提供的。

## 04、架构

引入 Flyway 之后，架构上把职责分开。Hibernate 只负责 ORM 映射，不负责修改数据库结构；Flyway 负责 Schema 演变，按版本执行迁移脚本。

迁移脚本统一放在 db/migration 目录，命名格式 V<版本号>__<描述>.sql。启动应用时，Flyway 会读取历史表 flyway_schema_history，找到未执行的版本，按顺序执行。生产环境更推荐的方式是：应用启动时只做 validate，不执行迁移；实际的 migrate 步骤放在发布流程里，由 CI/CD 或 DBA 在发布窗口执行。这样可以和审批、备份、监控结合起来。

同时，把 spring.jpa.hibernate.ddl-auto 设置为 none 或 validate。none 是完全不干预；validate 会在启动时校验 Entity 映射和数据库表是否一致，如果不一致直接报错，提醒开发者补迁移脚本。这相当于给生产环境加了一道保险。

## 05、实战

下面我们用 Flyway 完成一个真实演练：关闭生产自动改表，创建 customer、orders、order_item、inventory 四张表，并完成新增字段、索引和数据迁移。

第一步，配置生产环境。在 application-prod.yml 中设置：
spring.jpa.hibernate.ddl-auto: none
spring.flyway.enabled: true
spring.flyway.baseline-on-migrate: false

开发环境可以保留 update 或 create-drop，但生产必须 none。

第二步，引入 Flyway。Spring Boot 项目直接加依赖：
org.flywaydb:flyway-core

第三步，创建 V1__init_schema.sql，放在 src/main/resources/db/migration 下。内容示例：

CREATE TABLE customer (
  id BIGINT NOT NULL AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(255) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uk_customer_email (email)
) ENGINE=InnoDB;

CREATE TABLE orders (
  id BIGINT NOT NULL AUTO_INCREMENT,
  customer_id BIGINT NOT NULL,
  order_no VARCHAR(64) NOT NULL,
  total_amount DECIMAL(12,2) NOT NULL,
  status VARCHAR(20) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  KEY idx_orders_customer (customer_id),
  CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customer (id)
) ENGINE=InnoDB;

CREATE TABLE order_item (
  id BIGINT NOT NULL AUTO_INCREMENT,
  order_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  unit_price DECIMAL(12,2) NOT NULL,
  final_price DECIMAL(12,2) NOT NULL,
  PRIMARY KEY (id),
  KEY idx_order_item_order (order_id),
  CONSTRAINT fk_order_item_order FOREIGN KEY (order_id) REFERENCES orders (id)
) ENGINE=InnoDB;

CREATE TABLE inventory (
  id BIGINT NOT NULL AUTO_INCREMENT,
  product_id BIGINT NOT NULL,
  stock INT NOT NULL,
  reserved_stock INT NOT NULL,
  updated_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uk_inventory_product (product_id)
) ENGINE=InnoDB;

第四步，新增字段。创建 V2__add_customer_status.sql：
ALTER TABLE customer ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'ACTIVE';
UPDATE customer SET status = 'ACTIVE' WHERE status IS NULL;

第五步，新增索引。创建 V3__add_orders_idx.sql：
ALTER TABLE orders ADD INDEX idx_orders_status_created (status, created_at);

第六步，数据迁移。假设 order_item 原先用 unit_price 乘以 quantity 计算 final_price，现在要修正历史数据中的舍入误差。创建 V4__migrate_order_item_final_price.sql：
UPDATE order_item SET final_price = ROUND(unit_price * quantity, 2) WHERE final_price IS NULL OR final_price = 0;

第七步，执行迁移。本地或测试环境执行 mvn flyway:migrate，或者在应用启动时自动执行。生产环境建议在发布窗口手动执行 flyway migrate 命令，或者使用 CI/CD 流水线调用迁移插件。执行后检查 flyway_schema_history 表，确认版本记录和校验和。

第八步，把迁移脚本提交到 Git。每新增或修改一个脚本，都要走 PR 评审。CI 在测试库上自动执行 migrate，确保脚本可重复执行。生产发布时，把迁移作为发布步骤之一，和代码一起上线。

## 06、洞见

这一套做下来，最大的体会是：Entity 和 Migration 是两个层次的东西。Entity 描述目标模型，表达应用希望数据库长什么样；Migration 描述数据库如何从历史状态安全走到目标状态，是一条路径。自动改表试图用目标状态倒推路径，但数据库结构变更的路径往往不是唯一的，而且需要业务判断。

比如加一个非空字段，目标状态是列存在且非空。但路径可以是先加可空列，再回填数据，再改非空；也可以直接加带默认值的非空列。自动改表不会知道哪条路径对业务更安全。再比如拆分字段、合并表、数据清理，这些必须写迁移脚本，因为只有人知道数据该怎么变。

Baseline 也是常被忽略的点。很多团队引入 Flyway 时，库里已经有很多表，不能从零开始。这时要用 baseline 把当前状态标记为一个基准版本，后续脚本只描述增量变化。版本化迁移的本质，是把数据库结构纳入代码版本控制，让每次结构变化都有来源、有评审、有记录。

## 07、行动

如果你的生产环境还在用 ddl-auto=update，建议立刻行动：

第一，关掉生产自动改表，把 spring.jpa.hibernate.ddl-auto 改为 none 或 validate。

第二，对存量数据库执行 Flyway baseline，生成基线版本，确保后续迁移有起点。

第三，建立迁移脚本目录和命名规范，比如 V1__init_schema.sql、V2__add_customer_status.sql。

第四，所有 Schema Change 必须写成迁移脚本，提交 Git，走 PR 评审，不允许直接在数据库上手动改结构。

第五，在 CI 中增加数据库迁移校验步骤，每次提交都在测试库上跑一遍 migrate，验证脚本可重复执行。

第六，生产执行迁移前做好备份，并演练回滚或前滚方案。如果脚本不可回滚，至少要准备前滚脚本。

第七，定期检查 flyway_schema_history 表，确保版本记录和实际结构一致。

## 08、小结

生产数据库 Schema 不能靠 Entity 自动改，因为它只关心目标状态，不关心路径。Flyway 这样的版本化迁移工具，让每次结构变更都成为可评审、可追溯、可重复的脚本。Entity 负责描述目标，Migration 负责安全抵达。关掉 ddl-auto=update，把 Schema Change 纳入 Git 和 CI，是对生产环境最基本的尊重。

## 09、链接与概念说明

Hibernate DDL Auto：Hibernate 提供的自动建表/改表功能，常用值包括 none、validate、update、create、create-drop。生产环境建议 none 或 validate。

Flyway：数据库迁移工具，通过版本化 SQL 脚本管理 Schema 变更。核心概念包括 Versioned Migration、Baseline、flyway_schema_history 表、校验和。

Liquibase：另一个主流数据库迁移工具，支持 XML、YAML、JSON、SQL 等多种格式，适合需要多数据库兼容的场景。

Versioned Migration：带唯一版本号的迁移脚本，按顺序执行，执行记录持久化，保证只执行一次。

Baseline：对存量数据库设置基准版本，使迁移工具可以从该版本开始管理后续变更。

Online DDL：数据库在线结构变更技术，可以在改表时减少锁等待，适合大表加索引等操作。

参考文档：Hibernate 官方文档、Flyway 官方文档、Spring Boot 数据库迁移章节、MySQL 官方文档。

凌晨两点，订单表突然卡死，几十个连接在等待元数据锁，业务完全不可用。排查发现，发布时 Hibernate 自动改表，给一张两千万行的表加索引，还顺手调整了另一个字段类型。我是老李，经历过这种场面。开发环境里 ddl-auto=update 确实方便，实体类加个字段，重启就自动加列；改个注解，索引也自动修。但这种便利一旦带到生产，就变成了事故。

《Spring Boot + JPA 实战》第19招 表结构怎么演进

开发环境图方便开 ddl-auto=update，生产却可能引发锁表与数据丢失。本文从 Hibernate 自动建表说起，演示关闭自动改表并用 Flyway 完

架构师

数据库

后端

开发工具

生产环境Hibernate自动改表风险高，易致锁表与业务中断。采用Flyway版本化迁移，关闭ddl-auto=update，通过脚本管理Schema变更。Entity负责目标模型，Migration负责安全演进。实施步骤：配置none、引入Flyway、编写迁移脚本、纳入Git与CI评审，确保变更可追溯、可回滚。

数据迁移

流数据

容器

MySQL

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Boot + JPA 实战》第19招 表结构怎么演进-腾讯云开发者社区-腾讯云

《Spring Boot + JPA 实战》第19招表结构怎么演进

《Spring Boot + JPA 实战》第19招表结构怎么演进

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Boot + JPA 实战》第19招 表结构怎么演进

《Spring Boot + JPA 实战》第19招 表结构怎么演进

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Boot + JPA 实战》第19招表结构怎么演进

《Spring Boot + JPA 实战》第19招表结构怎么演进