推荐使用BIGINT（Long）而非字符串做主键，因其查询性能高、存储节省（仅8字节）、天然有序支持分页与范围扫描，且ORM兼容性强；常见生成方式包括数据库自增、号段模式、时间戳前缀及Snowflake算法。
Long 类型在数据库 ID 生成中，本质是使用 64 位有符号整数（取值范围：-9223372036854775808 到 9223372036854775807），但实际用作主键时几乎总是取非负值，即有效范围约 0～9.2×10¹⁸。这个量级足以支撑绝大多数业务的全生命周期ID需求，同时兼顾索引效率与存储紧凑性。
为什么推荐用 BIGINT（Long）而非字符串做主键
数据库中对应 Long 的标准类型是 BIGINT（MySQL/PostgreSQL）、NUMBER(19)（Oracle）等。相比 UUID 字符串，它有明显优势：
- 查询性能高：整数比较比字符串比对快得多，B+树索引更紧凑，IO 和内存开销更低
- 存储节省：BIGINT 固定占 8 字节；而标准 UUID 字符串（36 字符）需至少 36 字节，即使转为二进制 UUID（16 字节）仍多出一倍
- 有序性天然支持分页和范围扫描：自增或时间有序 Long ID 可直接用于 created_at 排序、游标分页等场景
- 兼容性强：所有主流 ORM（如 MyBatis、Hibernate、JPA）对 Long 主键支持完善，序列化/反序列化无歧义
常见 Long ID 生成方式及适用场景
不同架构下应选择匹配的生成策略，不能一概而论：
-
单库单表 + 中小规模应用 → 数据库 AUTO_INCREMENT：
MySQL 设置id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY，配合 JPA 的@GeneratedValue(strategy = GenerationType.IDENTITY)。简单、可靠、连续，适合管理后台、内部系统 -
分库分表或分布式部署 → 号段模式（Snowflake 变种）：
例如：高位 16 位固定系统编号 + 中位 16 位机器/实例 ID + 低位 32 位毫秒内自增。全部拼成一个 Long，通过数据库 sequence 表或 Redis 原子操作分配号段，避免单点瓶颈 -
强时间序 + 高并发写入 → 数据库序列 + 时间戳前缀：
PostgreSQL 可用nextval('seq')获取唯一序号，再结合当前毫秒时间左移后组合；MySQL 可用带时间戳的自定义函数（需注意时钟回拨） -
不依赖数据库、纯内存生成 → Twitter Snowflake 算法：
64 位拆分为：1 位符号位（固定为 0）+ 41 位毫秒时间戳 + 10 位机器 ID + 12 位序列号。Java 有成熟实现（如IdWorker），ID 单调递增且全局唯一
使用 Long ID 需要注意的关键细节
看似简单，实操中几个坑容易被忽略：
-
禁止手动 INSERT 指定 ID：除非明确关闭自增（
SET SQL_SAFE_UPDATES=0），否则显式插入已存在 ID 会报错；若必须覆盖，应先DELETE再INSERT，或用REPLACE INTO/ON DUPLICATE KEY UPDATE -
注意负数风险：Java 的
Random.nextLong()可能生成负值，入库前务必Math.abs()或& 0x7fffffffffffffffL清除符号位 - 分库分表时避免 ID 冲突：单纯用各库独立自增会导致重复，必须引入全局协调机制（如中心号段服务、ZooKeeper 分配 workerId）
- 警惕时钟回拨：Snowflake 类算法严重依赖本地时间，NTP 同步异常或人为改时间可能导致 ID 重复或降序，建议加入回拨检测与等待逻辑
Long ID 在实际建表中的写法示例
以 MySQL 8 为例，一个健壮的用户表定义应类似：
CREATE TABLE users (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键，全局唯一',
username VARCHAR(64) NOT NULL,
email VARCHAR(255) NOT NULL UNIQUE,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
KEY idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
关键点：加 UNSIGNED 扩展正数范围至 0～1.8×10¹⁹；显式注释说明用途；搭配时间索引支持按创建时间查询。
