SQL自增主键是关系型数据库中最常用的主键生成方式之一，很多开发者在创建表时会默认使用自增ID作为主键，认为这种方式简单高效。但在实际的高并发、大数据量场景下，自增主键往往会暴露出不少性能问题，需要结合具体业务场景调整设计思路。
自增主键常见的性能问题
高并发下的锁竞争问题
大部分数据库的自增主键生成依赖自增计数器，在并发插入数据时，多个事务需要同时获取自增计数器的值，就会产生锁竞争。以MySQL的InnoDB引擎为例，自增锁的持有时间会影响并发插入的性能，如果业务插入频率很高，锁竞争会成为性能瓶颈。
数据页分裂问题
自增主键的值是顺序递增的，新插入的数据会不断追加到B+树的末尾。但如果表中有其他索引，或者存在删除数据后重新插入的情况，就可能导致数据页分裂，增加磁盘IO开销，同时也会让索引的存储效率下降。
分布式场景下的ID冲突
单库自增主键只能保证单库内的ID唯一，在分库分表或者多数据库实例的场景下，不同实例的自增ID会出现重复，无法直接作为全局唯一标识，需要额外做ID冲突处理，增加了系统复杂度。
ID可预测的安全风险
自增ID的规律性很强，用户可以通过已获取的ID推测出其他数据的ID，比如订单表使用自增ID，用户可能通过遍历ID查询到其他用户的订单信息，存在数据泄露的安全隐患。
自增ID的设计思路
单库小流量场景：直接使用数据库自增
如果业务是单库部署，且数据量不大、并发量不高，直接使用数据库原生的自增主键是最省心的方案，不需要额外引入其他组件，维护成本低。以下是MySQL中创建带自增主键表的示例：
-- 创建用户表，使用自增ID作为主键 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` varchar(50) NOT NULL COMMENT '用户名', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
高并发单库场景：调整自增参数优化
针对高并发下的自增锁竞争问题，可以调整数据库的自增相关参数。比如MySQL可以设置innodb_autoinc_lock_mode参数为2，采用交叉锁模式减少锁持有时间，提升并发插入性能。同时可以根据业务预估的数据量，合理设置自增主键的类型，比如数据量超过21亿就不要用int类型，改用bigint类型避免溢出。
分库分表场景：使用分段自增或雪花算法
分库分表场景下，可以给每个数据库实例分配不同的自增ID段，比如实例1生成1-1000000的ID，实例2生成1000001-2000000的ID，避免ID冲突。也可以使用雪花算法生成趋势递增的ID，既保证全局唯一，又避免了单点自增计数器的瓶颈。以下是简单的雪花算法Java实现示例：
public class SnowflakeIdGenerator {
// 起始时间戳，可根据业务调整
private static final long START_TIMESTAMP = 1622505600000L;
// 机器ID位数
private static final long WORKER_ID_BITS = 5L;
// 数据中心ID位数
private static final long DATA_CENTER_ID_BITS = 5L;
// 序列号位数
private static final long SEQUENCE_BITS = 12L;
// 最大机器ID
private static final long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS);
// 最大数据中心ID
private static final long MAX_DATA_CENTER_ID = ~(-1L << DATA_CENTER_ID_BITS);
// 机器ID左移位数
private static final long WORKER_ID_SHIFT = SEQUENCE_BITS;
// 数据中心ID左移位数
private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;
// 时间戳左移位数
private static final long TIMESTAMP_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;
private long workerId;
private long dataCenterId;
private long sequence = 0L;
private long lastTimestamp = -1L;
public SnowflakeIdGenerator(long workerId, long dataCenterId) {
if (workerId > MAX_WORKER_ID || workerId < 0) {
throw new IllegalArgumentException("机器ID超出范围");
}
if (dataCenterId > MAX_DATA_CENTER_ID || dataCenterId < 0) {
throw new IllegalArgumentException("数据中心ID超出范围");
}
this.workerId = workerId;
this.dataCenterId = dataCenterId;
}
public synchronized long nextId() {
long currentTimestamp = System.currentTimeMillis();
if (currentTimestamp < lastTimestamp) {
throw new RuntimeException("时间戳回退，无法生成ID");
}
if (currentTimestamp == lastTimestamp) {
// 同一毫秒内序列号自增
sequence = (sequence + 1) & (~(-1L << SEQUENCE_BITS));
if (sequence == 0) {
// 序列号溢出，等待下一毫秒
currentTimestamp = waitNextMillis(lastTimestamp);
}
} else {
sequence = 0L;
}
lastTimestamp = currentTimestamp;
// 组装ID：时间戳部分 + 数据中心ID + 机器ID + 序列号
return ((currentTimestamp - START_TIMESTAMP) << TIMESTAMP_SHIFT)
| (dataCenterId << DATA_CENTER_ID_SHIFT)
| (workerId << WORKER_ID_SHIFT)
| sequence;
}
private long waitNextMillis(long lastTimestamp) {
long timestamp = System.currentTimeMillis();
while (timestamp <= lastTimestamp) {
timestamp = System.currentTimeMillis();
}
return timestamp;
}
}
安全要求高的场景：使用UUID或加密自增ID
如果业务对ID的不可预测性要求高，比如用户表、订单表，可以直接使用UUID作为主键，或者将自增ID通过加密算法生成不可逆的对外ID，内部存储仍然使用自增ID，既保证内部查询性能，又避免外部ID被遍历的风险。
不同设计思路的对比
以下是不同自增ID设计方案的优缺点对比，可根据业务场景选择：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 数据库原生自增 | 实现简单，无需额外组件，性能稳定 | 分布式场景冲突，高并发有锁竞争，ID可预测 | 单库小流量业务 |
| 调整自增参数优化 | 无需改代码，提升高并发下的插入性能 | 仍然无法解决分布式冲突问题 | 单库高并发业务 |
| 分段自增 | 解决分布式ID冲突，性能较好 | 需要维护ID段分配，有单点风险 | 分库分表业务 |
| 雪花算法 | 全局唯一，趋势递增，无单点问题 | 依赖时钟，实现复杂度稍高 | 分布式高并发业务 |
| UUID | 全局唯一，不可预测，无冲突 | 字符串类型，索引性能差，无序 | 安全要求高，数据量小的业务 |
总结
自增主键本身没有绝对的好坏，关键是要匹配业务场景。小流量单库场景直接用数据库自增即可，高并发场景可以调整参数优化，分布式场景优先选择分段自增或者雪花算法，安全敏感场景可以结合加密或者UUID。设计时要提前预估数据量和并发量，避免后期因为主键问题导致大规模重构，影响业务稳定性。