SQL主键设计核心目标是唯一标识数据、支撑高效索引、保障关系稳定；必须满足唯一非空、无业务含义、静态精简三原则；单机优选自增ID，分布式场景推荐Snowflake或UUID。
SQL主键设计的核心目标是：唯一标识每行数据、支撑高效索引、保障数据关系稳定。它不是随便选个字段填上就行，而是直接影响查询性能、写入吞吐、扩展能力和运维成本。
主键必须满足的三个硬性原则
1. 唯一性且非空：主键列不允许NULL，且整列（或联合列）值在全表中绝对不重复。这是数据库强制约束，违反会直接报错。
2. 不应承载业务含义：避免用手机号、身份证号、订单编号等业务字段做主键。这些值可能变更（如身份证升位）、存在合规风险、或导致外键级联更新灾难。
3. 尽量保持静态和精简：主键一旦生成，理想状态是永不修改；长度越短越好——INT（4字节）比CHAR(36)的UUID节省约90%索引空间，B+树层级更低，范围扫描更快。
自增ID：单机场景下的高效选择
MySQL中用AUTO_INCREMENT定义的整型主键，是中小规模系统最常用、最稳妥的方案。
- 插入时顺序追加，几乎不触发页分裂，写入吞吐高
- B+树聚簇索引天然紧凑，主键范围查询（如
WHERE id BETWEEN 1000 AND 2000）效率突出 - 开发简单：INSERT时不填ID字段，数据库自动分配
- 注意缺陷：无法跨库保证唯一；重启后自增值不重置，但事务回滚会导致ID“跳号”
分布式ID：应对分库分表与多实例场景
当系统演进到微服务、读写分离或水平分片阶段，单纯依赖数据库自增就不可行了。主流替代方案有：
- UUID：128位字符串，全局唯一，完全去中心化；缺点是无序插入引发索引碎片，存储和比较开销大
- 雪花算法（Snowflake）：64位数字，含时间戳+机器ID+序列号，结果趋势递增、毫秒内可并发生成多ID；兼顾唯一性、性能与可读性，适合中大型分布式系统
- 数据库号段模式：如预分配[1–1000]给服务A、[1001–2000]给服务B，由中心服务统一分发；平衡了DB依赖与扩展性
怎么选？看这三点就能定方向
看部署架构：单MySQL实例 → 优先自增；已分库或准备上K8s多副本 → 排除纯自增，选Snowflake或UUID。
看核心负载类型：写多读少、强调吞吐（如日志采集）→ Snowflake更稳；读多写少、大量范围查询（如报表导出）→ 自增仍是首选。
看安全与合规要求：需隐藏业务增长节奏（如对外暴露订单ID）→ UUID或Snowflake；内部系统、追求极致性能 → 自增ID足够可靠。
