MySQL 新增字段 Java 实体未同步的隐患与解决
在 Java + MySQL 的开发中，ORM 框架（如 MyBatis-Plus、Hibernate）虽然能简化映射，但数据库表结构变更后，如果 Java 实体类没有及时跟进，往往会在运行时埋下隐患。特别是涉及批量操作时，这种不同步可能导致静默失败或显式报错。
场景重现：当数据库变了，代码没变
假设我们有一个 statistics_data 表，对应的 Java 实体类如下：
@Data
@TableName("statistics_data")
public class StatisticsData extends BaseModel {
private String agentId;
private Long click;
// 其他字段...
}
此时，DBA 执行了以下变更，增加了一个非空字段：
ALTER TABLE statistics_data ADD COLUMN new_column INT NOT NULL;
程序继续运行，调用 saveBatch() 等批量方法，会发生什么？这取决于 ORM 框架的行为和字段的约束条件。
不同操作下的表现分析
1. 查询操作 (SELECT)
通常情况下，MyBatis-Plus 默认忽略数据库中存在但实体类缺失的字段。查询不会直接报错，但如果日志级别较高，可能会看到警告信息。不过，读取到的数据里会丢失这个新字段的信息，导致业务逻辑判断出错。
2. 插入操作 (INSERT)
这是最容易踩坑的地方。MyBatis-Plus 生成的 SQL 语句通常只包含实体类中定义的字段。
- 如果字段允许 NULL 或有默认值：SQL 不包含该字段，MySQL 会使用默认值或 NULL 填充，插入成功。
- 如果字段是 NOT NULL 且无默认值：SQL 缺少该字段，MySQL 会拒绝写入并抛出异常。
典型的错误日志如下：
ERROR 1364 (HY000): Field 'new_column' doesn't have a default value
这意味着你的代码看似正常，实际上因为字段缺失导致数据无法持久化。
3. 批量插入 (saveBatch)
saveBatch() 底层循环调用单条插入逻辑。一旦遇到上述 NOT NULL 约束，整个批次都会中断。对于高并发或大数据量的场景，这不仅影响性能，还可能导致部分数据丢失，排查起来非常麻烦。
解决方案：从临时修补到长期规范
方案一：临时修复（仅限紧急场景）
如果无法立即修改代码，可以通过调整数据库约束来绕过限制，但这只是权宜之计。
statistics_data MODIFY new_column ;
statistics_data MODIFY new_column ;
