主键必须是not null且unique；推荐用自增整数，避免uuid或字符串；联合主键需谨慎设计顺序与列选择；变更主键代价极高，需上线前定稿。
主键必须是 NOT NULL + UNIQUE
MySQL 的主键本质就是 PRIMARY KEY 约束，它自动附加 NOT NULL 和 UNIQUE 语义。如果手动定义主键列允许 NULL，建表会直接报错：ERROR 1171 (42000): All parts of a PRIMARY KEY must be NOT NULL。常见误操作是把业务字段（比如 email）设为主键又忘了加 NOT NULL，结果 DDL 失败。
实操建议：
- 显式写出
NOT NULL，别依赖隐式行为，增强可读性 - 避免用可能为空的业务字段（如
phone、nickname）当主键 - 复合主键要格外小心：所有列都必须
NOT NULL，且组合值全局唯一
优先用自增整数（INT/BIGINT）做主键
InnoDB 表的聚簇索引就是主键索引，数据按主键物理排序存储。自增整数天然满足递增、紧凑、无意义、写入局部性好这几个关键特性。换成 UUID 或字符串主键，会导致：
- 页分裂频繁（新记录随机插入到中间页），
Innodb_page_splits指标飙升 - 二级索引变大（每个二级索引节点都要存完整主键值），浪费空间
- 范围查询和排序性能下降（字符串比较比整数慢，且无法利用 CPU 预取）
示例对比：
-- 推荐（紧凑、顺序写入） CREATE TABLE user (id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, ...); <p>-- 不推荐（主键过长，破坏聚簇有序性） CREATE TABLE user (id CHAR(36) PRIMARY KEY, ...); -- UUID v4
联合主键设计要警惕“左前缀失效”和查询覆盖问题
当用多列组成主键（如 (tenant_id, order_id)），InnoDB 的聚簇索引只按该顺序物理排序。这意味着：
- 单独查
order_id无法走主键索引，必须建额外索引 - 查
tenant_id = ? AND order_id > ?能高效走主键；但order_id = ? AND tenant_id = ?虽然能用上，实际执行计划可能因统计信息不准而选错索引 - 如果常查
tenant_id+ 时间范围，把时间列加入联合主键尾部（如(tenant_id, created_at, order_id)）反而更糟——因为created_at非单调，破坏写入局部性
真正适合联合主键的场景有限：分库分表后本地唯一、强业务语义约束（如 (user_id, skill_name) 表示用户技能集）、或明确以该组合作为高频查询入口且不单独查询后置列。
主键变更代价极高，上线前必须定稿
修改主键（ALTER TABLE ... DROP PRIMARY KEY, ADD PRIMARY KEY (...)）在 InnoDB 中等价于重建整张表：复制数据、重建所有索引、锁表（或至少锁写）。即使使用 ALGORITHM=INPLACE，对大表仍可能卡住数小时，且期间 DML 可能失败或延迟。
容易被忽略的关键点：
- 外键引用该主键的子表也要同步调整，否则
ALTER会失败 - 应用层所有基于旧主键的缓存 key、日志 trace、关联查询逻辑全要检查
- ORM 框架（如 Django/SQLAlchemy）可能硬编码主键名为
id，换联合主键后需显式配置primary_key=False并重写逻辑
没有银弹。主键不是越短越好，也不是越“业务化”越好——它是存储引擎的底层契约，选型时得先想清楚数据生命周期、查询模式和扩展路径。
