Spring Data+JPA的Schema与数据库初始化的适用场景及使用方式是什么？

1. 测试环境是否要从手动维护表结构改为自动初始化模式？ #

分场景判断：

• 如果是本地开发环境、自动化单元/集成测试运行环境这类对数据无持久化要求的场景，非常建议切换。自动初始化能保证表结构和Java实体类完全对齐，避免手动改表漏改、配置不一致导致的异常问题，还能省去手动维护DDL脚本的重复劳动。
• 如果是团队共用的测试环境，不建议使用「先删表再重建」的自动初始化模式，容易误删其他成员的测试数据，可以切换为validate校验模式，仅校验实体和表结构是否匹配，表结构变更统一用版本化迁移工具管控。

2. 生产环境是否完全不建议依赖该功能？ #

绝大多数生产场景完全不建议使用，原因如下：

• JPA自动生成的DDL通常没有优化，可能出现字段类型不符合业务要求、索引缺失、约束不合理等问题，不符合生产环境的管控规范。
• 自动DDL执行过程不可控，容易出现锁表、误改字段、数据丢失等严重线上故障，生产环境的表结构变更必须走人工评审、灰度执行的流程。
  仅有一种极端场景可以考虑使用：无状态、数据不需要持久化的临时运行类应用，比如跑完即销毁的离线计算任务，这类应用即使表数据丢失也不影响业务。

3. 生成或初始化操作是否应该仅运行一次？为什么会有人选择频繁丢失数据？ #

初始化操作的运行次数由配置决定，没有强制要求仅运行一次。
选择频繁执行初始化、接受数据丢失的场景，本身就对数据没有持久化需求：

• 本地开发时每次修改实体类后重启应用，自动重建表可以直接生效新的结构，不需要手动调整数据库。
• 自动化测试执行时，每次用例运行前初始化数据库，可以保证测试环境干净，避免前序用例的残留数据影响本次测试结果，保障测试结果的可复现性。

4. JPA的drop-and-create动作的作用是什么？什么场景下需要主动删除表？UAT测试数据这类场景要如何适配该功能？ #

drop-and-create的作用是：应用启动时，先删除所有和实体类对应的数据库表，再按照实体类的配置重新生成表结构。
需要主动删表的场景都是对数据无持久化要求、需要每次运行都拿到干净环境的场景，比如本地调试、自动化单元/集成测试运行。
针对需要保留测试数据的UAT环境，不要使用drop-and-create模式，可做如下适配：

• 将JPA的DDL策略调整为validate，仅校验实体类和现有表结构是否匹配，不执行任何修改操作。
• 表结构变更统一使用Flyway、Liquibase这类版本化数据库迁移工具管控，所有变更都有可追溯的脚本，不会误删UAT的测试数据，也能保证多环境表结构的一致性。

内容的提问来源于stack exchange，提问作者Half_Duplex