JpaRepository中为何普遍使用Long类型而非其他数据类型

取值范围适配绝大多数业务场景 #

• 常用的32位整型Integer最大值仅为2^31-1（约21亿），中大型业务的用户表、订单表、日志表等很容易触及上限，出现主键溢出的严重问题。
• 64位有符号的Long类型最大值为2^63-1（约922亿亿），哪怕每秒生成100万条数据，也可支撑数十万年内的主键生成需求，完全覆盖几乎所有业务场景的数据量要求。

兼容主流主键生成策略 #

• JPA原生支持的主流主键生成规则天然适配Long类型，比如数据库自增主键、序列主键、雪花算法分布式主键：其中雪花算法生成的ID本身就是64位数值结构，和Long长度完全匹配，不需要额外做类型转换。
• 其他常见主键类型的通用性远低于Long：Short取值范围过小，仅能用于数据量极少的字典配置类表；String类型主键占用存储空间大，索引查询、排序效率远低于数值类型。

框架与生态适配性最优 #

• Spring Data JPA官方文档、默认示例均采用Long作为主键类型，生态适配性最好，新手使用过程中不容易出现泛型不匹配、序列化异常等低级错误。
• 常见的ORM插件、分库分表组件、分页工具对Long类型主键的兼容度最高，不需要额外做类型转换、序列化配置即可直接使用。

数据库层面性能优势明显 #

• 数值类型的主键在数据库中的查询、排序、比较效率远高于字符串等其他类型，存储成本也更低：Long类型在MySQL中仅占8字节，相同位数的字符串至少要占用16字节，数据量越大，索引存储和查询的性能差距越明显。
• 自增Long类型主键写入时是有序的，不会导致InnoDB聚簇索引出现页分裂问题，可大幅提升批量写入的性能。

补充：可选替代Long的场景 #

只有满足明确的特殊需求时才考虑替换主键类型：

• 数据量稳定不超过10万的配置表、字典表，可选用Integer降低存储成本
• 有强制业务要求主键携带业务标识的场景，推荐保留Long作为物理主键，额外新增字符串类型的逻辑业务主键使用，避免影响数据库性能

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