设计SQL表时：用现有唯一列还是新增id列做主键？

在设计SQL表时，要不要用业务唯一列替代通用自增id做主键，核心得从性能、关联成本、业务稳定性三个维度权衡，下面针对你的疑问逐一拆解：

1. 性能影响分析 #

• 数据量较大时：字符串类型主键的性能确实不如自增整数ID。以InnoDB为例，主键是聚簇索引，主键的大小直接影响二级索引的存储体积（二级索引叶子节点会存储主键值），字符串比整数占用更多空间，会导致索引占用更多内存/磁盘，查询时IO成本更高；另外自增ID是有序的，插入时不会频繁触发页分裂，而无规则的字符串主键插入时容易产生页分裂，影响写入性能。
• 数据量极少时（如不足100条）：性能差异可以忽略不计。此时无论是字符串主键还是自增ID，数据库的IO和索引维护成本都极低，业务上完全感知不到区别。

2. 字符串主键做外键关联的问题 #

直接用字符串业务列做主键关联外键，主要存在以下潜在问题：

• 存储成本高：外键列会存储主键的完整字符串值，关联表越多、数据量越大，额外占用的存储空间就越多，长期来看会增加存储成本和查询时的IO开销。
• 业务变更风险：如果这个字符串列的业务规则发生变化（比如原本的用户唯一标识从用户名改成邮箱，或者需要调整格式），那不仅要修改当前表的主键值，还要同步修改所有关联表的外键值，操作复杂度极高，还容易引发数据不一致。
• 关联查询效率：字符串的比较速度比整数慢，关联查询时的JOIN操作性能会比整数主键差一些，数据量大时这个差异会更明显。

方案选择建议 #

• 不建议常态化用字符串业务列做主键：除非你的业务场景满足两个条件：一是该业务列的规则绝对稳定（永远不会变更），二是数据量极小且长期不会增长。
• 优先保留自增id主键，给业务唯一列加unique索引：这种方案兼顾了性能和业务需求——自增ID保证了主键的高效性，unique索引确保业务列的唯一性，同时避免了业务变更带来的主键修改风险。
• 特殊场景的例外：比如你遇到的mysqldump导出UUID主键的问题，这种临时应急场景可以临时切换，但如果是长期架构设计，还是建议回到自增ID+唯一索引的方案，或者改用有序UUID（如带时间戳的UUIDv1版本）来解决导出问题，而非替换成字符串业务主键。

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