Spring Boot多数据源场景下的ddl-auto默认值问题解析

在Spring Boot应用开发中，当配置多个数据源时，EntityManagerFactoryBuilder对ddl-auto属性的默认处理机制可能会引发一些意料之外的行为。这个问题在Spring Boot 3.4.x版本中表现得尤为明显，值得开发者特别注意。

问题背景

在Spring Boot 3.3.5及更早版本中，当应用配置了多个数据源（其中包含嵌入式数据库）且未显式设置spring.jpa.hibernate.ddl-auto属性时，系统会按照文档描述的行为工作：仅对嵌入式数据库默认使用create-drop策略，其他数据源则采用none策略。

然而在升级到3.4.3版本后，开发者发现这个默认行为发生了变化：只要存在嵌入式数据库，所有数据源都会默认采用create-drop策略。这种改变可能导致生产环境数据库被意外清空，存在数据丢失的风险。

技术原理分析

这个行为变化的根源在于Spring Boot 3.4.0版本对EntityManagerFactoryBuilder的改造。主要变更点包括：

1. ddl-auto设置现在由主数据源（Primary DataSource）决定
2. 这些设置会被应用到自动配置的EntityManagerFactoryBuilder上
3. 当开发者注入这个builder来创建多个LocalContainerEntityManagerFactoryBean时，它们都会继承主数据源的ddl-auto配置

这种机制在单数据源场景下工作良好，但在多数据源环境下就可能产生问题。特别是当主数据源是嵌入式数据库时，所有通过该builder创建的EntityManagerFactory都会默认采用create-drop策略。

解决方案与最佳实践

目前推荐的临时解决方案是：

1. 确保生产环境使用的数据源被标记为@Primary
2. 显式设置spring.jpa.hibernate.ddl-auto属性
3. 对于嵌入式数据库，单独配置其ddl-auto策略

从技术实现角度看，更理想的解决方案应该是：当在builder上配置DataSource时，如果ddl-auto尚未显式配置，就根据当前DataSource的类型重新确定默认值。Spring Boot团队已经将此问题标记为需要修复的回归问题。

深入思考

这个问题引发了两个重要的架构考量：

1. 默认值安全性：create-drop虽然对开发环境方便，但作为默认值是否风险过高？特别是可能影响生产环境时。

2. 配置继承机制：从主数据源继承默认配置到所有数据源是否合理？也许应该为每个数据源单独确定其默认行为。

开发者建议

在实际项目开发中，建议：

1. 无论使用哪个Spring Boot版本，都显式配置ddl-auto属性
2. 在多数据源场景下，为每个数据源单独配置JPA相关属性
3. 升级Spring Boot版本时，特别注意数据源相关的变更日志
4. 生产环境部署前，充分测试数据库初始化行为

Spring Boot团队已经意识到这个问题的重要性，并计划在后续维护版本中修复。开发者应关注官方更新，及时应用修复版本。同时，这也提醒我们在使用框架的自动配置功能时，需要充分理解其背后的工作机制，特别是在涉及数据持久化等关键功能时。