数据库中id字段一般使用哪种数据类型，有哪些常见选择？

在数据库设计中，ID 字段是每条记录的唯一标识符。它不仅决定了数据的完整性，还直接影响查询速度、存储占用还有程序的可 性。

常见痛点与需求

• 唯一性保障保证不同表、不同数据库甚至跨集群的数据不会冲突。
• 查询性能ID 必须能被高效索引，避免因类型过大导致 B+Tree 层级增高。
• 存储占用大型业务往往需要数十亿级别记录，存储空间会成为瓶颈。
• 业务可读性某些场景下需要人类可读的 ID。
• 安全与隐私ID 的公开暴露可能泄露业务规模或使用者信息，需要慎重考虑。

1️⃣ 整数类型

a) INT / BIGINT

INT : 4 字节，范围约 ±21 亿；BIGINT : 8 字节，范围约 ±9.22×10¹⁸；

优点：

• 高效的索引和排序操作。
• AUTO_INCREMENT 能让数据库自动分配唯一值，开发成本低。
• 占用空间小，适合大多数业务。其实，

缺点：

• ID 长度固定。一旦超出范围需迁移表结构。怎么说呢，
• AUTO_INCREMENT 在分布式环境下难以保证全局唯一。 需要额外方案，

b) TINYINT / SMALLINT

仅用于记录数目非常少的表，如配置表或状态码表。占用空间极小，但若错误使用会导致溢出。

2️⃣ UUID / GUID

再看特点。

• UUID,通常以字符串形式保存为36 位。

• No coordination needed – each node can generate IDs independently.
• No “gap” problem – IDs can be generated offline before persistence.

• ID 长度大，对索引层级影响显著； 查询时 B+Tree 层更深，速度慢于整数主键。

3️⃣ 自定义字符串 ID

# 用途示例：

• : “ORD20260815001”。可直观体现业务信息，怎么说呢，

: “”。不再是数字序列，

---

• SaaS 或多租户程序常使用前缀 + 数字组合，如 “TEN‑001234”。既能区分租户，又保持一定可读性。

---

# 使用注意事项：

1. "长度要足够"：若采用 VARCHAR。请确保不超长，否则会浪费存储且导致索引膨胀。

---

对比

INCREMENT

ID 类型	适用场景	性能	存储占用
INTEGER AUTOINCREMENT	单机或需集中生成	快	4 或 8
BIGINT AUTO
大数据量、长期	快	8
UUID/GUID	分布式、多租户、全球唯一	慢	16
自定义字符串	业务特定需求	中等~慢	可变长度。根据设计而定
TINYINT/SMLILNT等小型整数	配置表、小量记录 \t\t\t\t\t\t\t\t\t\t
注：所有数字均为近似值，非整数类型，请关注索引大小与查询延迟\"'>\t  *\t  \t  **" /> \

 \\end{table}\r")

。