在 SQLite 中，给主键加上 AUTOINCREMENT 是很多从其他关系型数据库迁移过来的习惯性操作。但 SQLite 的行号机制与 MySQL、SQL Server 并不相同，INTEGER PRIMARY KEY 本身就会自动分配一个整数主键，而 AUTOINCREMENT 只是在其上增加了一条防重用约束。理解两者的底层差异，能帮助我们在建表时省去不少无谓的写入负担。
一、INTEGER PRIMARY KEY 与 AUTOINCREMENT 的底层差异
SQLite 的每一张表默认都带有一个隐藏的 rowid 列，除非建表时使用了 WITHOUT ROWID。当某一列被声明为 INTEGER PRIMARY KEY 时，这个列就会成为 rowid 的别名，插入记录时如果未显式给该列赋值，SQLite 会自动挑选一个整数。这个整数通常比当前表里出现过的最大 rowid 还要大 1，但它并不保证永远不回填。
关键差异在于删除行为。对于普通的 INTEGER PRIMARY KEY，如果表里最大的 rowid 是 100，删掉这行后再插入新行，SQLite 完全可能重新分配 100，因为此时 100 是空闲的。这个行为在多数内部表场景下没有影响，因为主键只要唯一即可。而 AUTOINCREMENT 会强制记录历史上使用过的最大 rowid，即使该行被删除，后续插入也只会从更大的值开始，绝对不会重用旧值。
可以用下面的建表语句做个对比：
CREATE TABLE users_normal (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE users_auto (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL
);
INSERT INTO users_normal(name) VALUES ('Alice');
INSERT INTO users_normal(name) VALUES ('Bob');
DELETE FROM users_normal WHERE id = 2;
INSERT INTO users_normal(name) VALUES ('Carol');
-- 这里 users_normal 的新行 id 有可能重新变成 2
INSERT INTO users_auto(name) VALUES ('Alice');
INSERT INTO users_auto(name) VALUES ('Bob');
DELETE FROM users_auto WHERE id = 2;
INSERT INTO users_auto(name) VALUES ('Carol');
-- 这里 users_auto 的新行 id 不会再用 2，而是继续向后分配
从业务表面看，两者都能得到唯一的整数主键；但如果你只关心主键唯一而并不关心某个 ID 是否曾经属于一条已删除记录，那么 AUTOINCREMENT 提供的保证就是一个额外功能。这个功能不是免费的，它会引入额外的内部状态维护。
二、AUTOINCREMENT 带来的性能与存储开销
AUTOINCREMENT 的实现依赖 SQLite 内部的一张系统表 sqlite_sequence。这张表记录每个启用了 AUTOINCREMENT 的表名，以及该表历史上分配过的最大 rowid。每次插入新行时，SQLite 除了要写入数据页和索引页，还要额外更新 sqlite_sequence 中的对应记录。这个更新动作需要在事务中完成，会增加写操作的次数，也可能扩大写事务的锁持有时间。
在单条插入时，这点开销可能感受不到；但在批量导入或高频写入场景下，每一条插入都多一次系统表写入，积累起来就会拉开差距。尤其是在同一个事务中插入大量数据时，sqlite_sequence 的频繁更新可能产生额外的页分裂和脏页写入，导致整体吞吐下降。你可以通过关闭 AUTOINCREMENT，改用普通 INTEGER PRIMARY KEY 来做对照测试，通常会发现后者的插入速度更快。
另一个代价是并发层面的。SQLite 采用库级写锁，任何写操作都需要独占数据库文件。虽然普通插入也需要写锁，但 AUTOINCREMENT 多出来的系统表更新会让写事务的实际执行时间变长。对于多线程或多进程同时写 SQLite 的环境来说，更长的写事务意味着更高的锁等待概率。很多 SQLite 并发性能问题并不是因为数据库本身不行，而是因为没必要的写放大被忽略。
此外，AUTOINCREMENT 还会限制 rowid 的分配策略。普通 INTEGER PRIMARY KEY 在到达整数上限时会尝试寻找未被使用的正整数，而 AUTOINCREMENT 一旦用完了可以分配的范围，会直接返回 SQLITE_FULL 错误。虽然这种情况在一般业务里很少发生，但它说明该项功能是为了防止 ID 重用而设计的严格约束，而不是用来做常规自增的默认选项。
三、哪些场景才真正需要 AUTOINCREMENT
判断是否需要 AUTOINCREMENT，核心看业务是否依赖删除记录后的 ID 永不复用。一个典型场景是数据对外暴露过，例如用户看到的订单号、工单号、发票号等。如果一条订单记录被删除，而系统后来又生成了一条相同编号的新订单，就可能造成对账混乱、历史引用歧义甚至安全问题。此时普通 INTEGER PRIMARY KEY 的重用行为会带来风险，AUTOINCREMENT 的防重用保证就有价值。
另一个常见场景是数据同步和日志关联。主从同步、增量备份、审计日志等系统经常用主键作为稳定标识来判断某条记录是否已经被处理过。如果主键会重用，下游系统可能把一个新记录误判为旧记录，或者把删除后的重分配当成数据回滚，从而破坏一致链路。需要长期保存、跨表引用、外部系统读取的 ID，通常都应避免重用。
但对纯内部表、临时表、中间计算表，或者主键只用于表内唯一性约束的情况，根本没有必要启用 AUTOINCREMENT。比如用户表、商品表、日志表，如果业务上允许删除后新记录复用旧 ID，或者 ID 只在数据库内部使用，那么普通 INTEGER PRIMARY KEY 足够。把它换成 AUTOINCREMENT，只会白白增加维护系统表的成本。
还有一点容易被误解：很多人以为普通 INTEGER PRIMARY KEY 会随机分配或不能自增，其实它一样是按当前最大值加 1 分配。只有在删除最大 rowid 并再次插入时，才可能出现重用。如果你的表从来不删除数据，或者从来不删除最新的那几行，那么两者的实际表现几乎一致，但普通模式没有额外系统表写入。
四、建表时的实践建议
大多数 SQLite 表结构都可以直接使用 INTEGER PRIMARY KEY，不必加上 AUTOINCREMENT。例如：
CREATE TABLE logs (
id INTEGER PRIMARY KEY,
level TEXT NOT NULL,
message TEXT NOT NULL,
created_at TEXT DEFAULT (datetime('now'))
);
只有当 ID 可能被外部引用、删除后可能造成语义冲突时，才考虑启用 AUTOINCREMENT：
CREATE TABLE orders ( order_id INTEGER PRIMARY KEY AUTOINCREMENT, customer_name TEXT NOT NULL, amount REAL NOT NULL );
如果不想依赖整数主键的自动分配，也可以采用显式生成标识的方案。比如使用 UUID 或雪花 ID，由应用层生成并写入主键列。这时建表时可以直接声明 id TEXT PRIMARY KEY，不涉及 rowid 分配，也就没有重用或序列维护的问题。这种方案的代价是主键更长、索引体积更大，但换来了分布式无冲突和更强的业务可控性。
最后，关于从其他数据库迁移的习惯需要调整。MySQL 的 AUTO_INCREMENT 和 SQLite 的 AUTOINCREMENT 在语义上有重叠，但底层实现完全不同。在 SQLite 中，自增只是 INTEGER PRIMARY KEY 的附带能力，AUTOINCREMENT 更像是附加的防重用约束。把每个主键都写成 INTEGER PRIMARY KEY AUTOINCREMENT 并不是推荐的默认做法。先问一句：这个 ID 在记录删除后是否绝对不能再次出现？如果答案是否定的，那就不需要 AUTOINCREMENT。
SQLiteAUTOINCREMENTINTEGER PRIMARY KEY修改时间：2026-09-17 18:03:50