POS系统中商品、客户等实体ID应使用自增long还是UUID？

核心结论 #

针对POS系统的场景，可以优先按业务部署模式选择：如果是纯云端集中部署、所有数据统一入库的单库架构，long型自增ID是非常成熟的良好实践；如果有多门店离线录入、多库同步、分布式部署需求，推荐用雪花算法这类有序分布式ID，UUID一般不推荐作为主键使用。

1. long型自增ID的优劣势 #

• 优势：
  • 性能极高：数据库原生支持，插入时有序递增，不会产生索引页分裂，写入性能是所有方案里最高的，索引占用空间也只有8字节，比UUID小一半以上
  • 可读性好：数字ID排查问题、和业务人员对齐数据时非常方便，不需要处理冗长的字符串
  • Java侧适配简单：直接用Long类型接收即可，不存在序列化、格式转换的坑
• 劣势：
  • 仅适用单库单表或者分库分表有中间件生成ID的场景，多节点独立生成ID会出现重复
  • 对外暴露时容易被爬取数据：比如第三方拿订单ID遍历就能估算出平台的单量规模，对外接口使用的话建议单独做一层映射不要直接暴露自增ID
  • 不支持离线录入场景：如果POS机断网时也要新增商品、开单，没连上数据库的时候拿不到自增ID，没法本地存储数据后续同步

2. UUID的优劣势 #

• 优势：
  • 本地即可生成，全局唯一，支持分布式、离线场景
• 劣势：
  • 无序性会导致数据库索引页频繁分裂，写入性能下降非常明显，数据量过百万后性能差距会被进一步放大
  • 字符串存储至少占用16字节，索引占用空间大，关联查询性能也远低于long型ID
  • 没有可读性，排查问题时很难靠ID快速定位对应数据
    注意：即便是优化后的有序UUID版本，也仅推荐用作外部不重复标识比如核销码、对外公开的唯一标识，不建议作为数据库主键使用

3. 更适配POS场景的补充方案：雪花算法（Snowflake） #

如果你的POS系统有离线使用、多门店多库同步的需求，优先选雪花算法生成的long型分布式ID，兼顾了自增ID的所有优势，同时支持分布式节点本地生成：

• 生成的是8字节的long型数字，和自增ID一样占用空间小、索引性能高
• 整体趋势有序，不会产生索引页分裂，写入性能接近自增ID
• 每个节点可以独立生成ID，不需要依赖数据库，POS离线时也能本地生成ID存数据，联网后直接同步即可，不会出现ID冲突
• Java生态有很多成熟的工具类可以直接调用，不需要自己实现复杂逻辑

具体选型建议 #

• 如果是单门店用的小型POS，数据都存在本地数据库或者单云端库，没有多节点同步、离线录入需求，直接用long自增ID就足够，是性价比最高的方案
• 如果是连锁POS、有多门店需要数据同步、或者POS需要支持断网开单/录商品，直接用雪花算法生成分布式ID即可
• 不管选哪种主键，对外提供接口、或者打印到小票上的公开编号，不要直接使用数据库主键，可以单独生成一套业务编号（比如商品编码用SPU+自增数，客户编号用C+日期+自增数），避免暴露主键带来的安全问题

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