主键与实体ID的区别及选型咨询：字符串主键vs自增主键

这是数据库设计里非常常见的权衡问题，我会从性能、维护成本、业务适配三个维度帮你拆解两种方案的优劣：

方案一：将15字符的逻辑ID设为主键 #

优点 #

• 业务直接友好：主键就是业务中实际使用的标识（比如pay_xyz123、order_xyz），无需额外做ID映射，查询或关联数据时可以直接用业务ID操作，减少代码层的转换逻辑。
• 全局唯一性天然满足：如果你的逻辑ID本身就是全局唯一的（比如跨服务统一生成），不需要依赖数据库自增机制，很适合分布式系统场景。

缺点（核心在性能影响） #

• 索引存储开销大：15字符的字符串（假设用VARCHAR(15)），在MySQL InnoDB这类数据库中，每个主键索引条目占用的空间远大于数字类型：INT仅4字节，BIGINT是8字节，而字符串按UTF-8算至少15字节，甚至更多。这会导致索引页能容纳的条目数大幅减少，查询时需要更多IO操作，直接降低查询性能。
• 插入时的索引碎片问题：如果你的逻辑ID不是严格递增的（比如pay_xyz123之后插入order_xyz，再插入pay_xyz124），InnoDB的B+树索引会频繁分裂，产生大量碎片，不仅影响插入性能，长期下来还会增加存储空间占用，需要定期优化表。
• 关联查询性能下降：当其他表用这个字符串主键作为外键时，关联查询的开销会比数字外键高很多，本质还是存储和索引查找的成本更高。

方案二：自增数字主键 + 逻辑ID设为唯一键 #

优点 #

• 极致的性能表现：自增数字主键（INT或BIGINT）的索引存储极小，B+树的层级更少，查询和插入的IO开销都很低。而且自增主键插入时是顺序写入，不会产生索引碎片，性能稳定且维护成本低。
• 数据库友好性高：数字主键的操作（插入、更新、关联）都是数据库最擅长的场景，各类优化工具和默认配置对数字主键的支持也更完善。
• 唯一键保障业务规则：通过给逻辑ID添加UNIQUE约束，既能保证业务标识的唯一性，又不会牺牲主键的性能优势。

缺点 #

• 多一层映射逻辑：代码层需要在插入时同时维护自增主键和逻辑ID，查询时可能需要先通过逻辑ID查到自增主键，再做关联操作（不过大多数ORM框架可以自动处理这种映射，实际开发成本不算高）。
• 分布式场景需额外处理主键唯一性：如果是多库多表的分布式系统，自增主键需要额外做全局唯一处理（比如用雪花算法、UUID或者分库分表的主键策略），但这属于分布式系统的通用问题，和逻辑ID本身无关。

总结：怎么选？ #

• 优先选自增主键+唯一键的场景：
  • 单库单表或数据量较大（千万级以上）的场景，追求极致性能；
  • 业务逻辑对主键没有强依赖，只需要逻辑ID作为业务标识；
  • 数据库以OLTP（在线事务处理）为主，频繁进行插入、更新、关联操作。
• 可以选字符串逻辑ID作为主键的场景：
  • 分布式系统中，逻辑ID是全局唯一的业务标识，且跨服务直接使用；
  • 数据量较小，性能影响可以忽略；
  • 业务需求中主键必须和业务标识一致，不想增加额外的映射层。

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