SpringBoot项目里，Mybatis-Plus的主键策略（IdType）到底怎么选？AUTO、INPUT还是NONE？

Mybatis-Plus主键策略深度解析从AUTO到ASSIGN_ID的工程实践1. 主键设计的核心考量因素在数据库设计中主键的选择往往被许多开发者视为小事直到项目遇到性能瓶颈或数据迁移难题时才追悔莫及。Mybatis-Plus提供的多种主键策略IdType绝非简单的配置差异而是关系到系统全局的基础架构决策。主键设计的三个黄金法则唯一性确保每条记录都有全局唯一标识稳定性主键值一旦生成就不应改变高效性生成算法需要考虑性能影响以电商系统为例订单表若采用数据库自增IDIdType.AUTO在分库分表场景下就会遭遇ID冲突而用户表若使用UUID当数据量达到千万级时索引效率会明显下降。这些真实场景的痛点正是我们需要深入理解主键策略的原因。2. Mybatis-Plus主键策略全景解析2.1 AUTO传统自增的现代困境TableId(type IdType.AUTO) private Long id;适用场景单机版MySQL/PostgreSQL应用不需要数据迁移的简单业务开发测试环境快速原型搭建性能表现MySQL 8.0测试数据并发线程数TPS事务/秒平均延迟(ms)101250850340014100480021注意AUTO策略在分布式系统中会导致ID冲突且批量插入时需要额外处理获取ID的逻辑2.2 INPUT完全掌控的代价TableId(type IdType.INPUT) private String customId;最佳实践场景使用业务规则生成ID如订单号ORD20230801-001历史数据迁移需要保持原ID与外部系统对接需要特定ID格式实现案例// 使用日期随机数生成订单ID public String generateOrderId() { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyyMMdd); String date LocalDate.now().format(formatter); int random ThreadLocalRandom.current().nextInt(1000); return ORD date - String.format(%03d, random); }2.3 ASSIGN_ID分布式时代的解决方案TableId(type IdType.ASSIGN_ID) private Long distributedId;技术原理 基于雪花算法Snowflake的改良实现64位Long型ID包含1位符号位固定为041位时间戳约69年10位工作机器ID支持1024个节点12位序列号每毫秒4096个ID性能对比测试策略类型单机QPS分布式QPSID大小AUTO5000不支持8字节UUID3000300032字节ASSIGN_ID800080008字节3. 混合策略与高级配置技巧3.1 多租户系统的ID设计在SaaS应用中通常需要租户隔离与全局唯一的平衡TableId(type IdType.ASSIGN_ID) private Long globalId; TableField(tenant_id) private String tenantId;联合索引建议ALTER TABLE user ADD UNIQUE INDEX idx_tenant_user (tenant_id, global_id);3.2 自定义ID生成器实现IdentifierGenerator接口可创建业务特定的ID生成器public class CustomIdGenerator implements IdentifierGenerator { Override public Number nextId(Object entity) { // 实现自定义逻辑 return DistributedId.nextId(); } }配置方式mybatis-plus: global-config: db-config: id-type: assign_id identifier-generator: com.example.CustomIdGenerator3.3 批量插入的性能优化不同策略对批量插入的影响策略万条数据插入时间需要额外SQLAUTO1200ms是ASSIGN_ID350ms否INPUT400ms否提示使用ASSIGN_ID时配置mybatis-plus.global-config.db-config.id-worker可优化工作节点分配4. 决策树如何选择最佳策略图示根据业务场景选择主键策略的决策流程关键问题自查清单是否需要跨数据库/分片唯一 → 考虑ASSIGN_ID是否有历史数据迁移需求 → 考虑INPUT是否在意存储空间和索引效率 → 避免UUID是否需要业务含义的ID → 自定义生成器是否追求极致插入性能 → 对比AUTO与ASSIGN_ID主流数据库推荐配置数据库类型单机推荐分布式推荐MySQLAUTO/ASSIGN_IDASSIGN_IDPostgreSQLASSIGN_IDASSIGN_IDOracleINPUT/SEQUENCEASSIGN_IDMongoDBASSIGN_IDASSIGN_ID在实际项目评审中我通常会建议团队优先考虑ASSIGN_ID除非有明确的业务限制。最近参与的一个物联网平台项目从最初的AUTO迁移到ASSIGN_ID后不仅解决了分库问题还将插入性能提升了40%这个经验值得分享。