MyBatis-Plus 处理非主键自增ID的最佳实践

背景介绍

在数据库设计中，自增ID通常被用作主键，但在某些特殊场景下，开发人员可能会选择将自增ID作为非主键字段使用。这种情况在使用MyBatis-Plus时可能会遇到一些特殊问题，特别是在SQL Server数据库中。

问题分析

当数据库表结构满足以下条件时，就会出现所述问题：

1. 表中有自增ID字段（identity(1,1)）
2. 自增ID不是主键
3. 主键是其他类型字段（如GUID或字符串）

这种情况下，MyBatis-Plus自动生成的代码会产生两个主要问题：

1. 更新问题：执行update操作时会尝试更新自增ID字段，导致数据库报错
2. 回填问题：执行insert操作后无法自动获取自增ID的值

技术解决方案

方案一：手动配置字段策略

对于更新问题，可以通过在实体类中为自增ID字段添加更新策略注解来解决：

@TableField(value = "id", updateStrategy = FieldStrategy.NEVER)
private Integer id;

这种方式明确告诉MyBatis-Plus在执行更新操作时忽略此字段。

方案二：自动识别处理

理想情况下，MyBatis-Plus可以通过以下方式自动处理非主键自增ID：

1. 在代码生成阶段识别自增列
2. 为非主键自增列自动添加忽略更新策略
3. 对于支持RETURNING语法的数据库，尝试获取自增值

数据库兼容性考虑

不同数据库对自增列的处理方式存在差异：

1. SQL Server：使用IDENTITY属性标识自增列
2. PostgreSQL：区分GENERATED ALWAYS和GENERATED BY DEFAULT
3. MySQL：AUTO_INCREMENT属性

MyBatis-Plus需要针对不同数据库采用不同的元数据查询方式，以准确识别自增列属性。

最佳实践建议

1. 明确字段用途：在设计阶段明确自增ID的用途，尽量避免非主键自增ID的设计
2. 代码生成配置：如果必须使用非主键自增ID，应在代码生成器中配置相关策略
3. 手动处理回填：对于不支持RETURNING的数据库，在插入后手动查询获取自增ID值
4. 统一策略：项目中应统一非主键自增ID的处理方式，避免不同开发人员采用不同方案

总结

MyBatis-Plus作为优秀的ORM框架，在处理常规场景时表现优异，但在面对非主键自增ID这种特殊设计时，需要开发人员额外注意。通过合理的注解配置和代码生成策略，可以很好地解决这类问题，保证项目的稳定性和可维护性。