在SQLite中，自增主键并不是由数据类型决定的，而是由主键列是否为INTEGER类型以及是否添加AUTOINCREMENT这两个条件共同决定的。SQLite会给每张普通表隐式分配一个64位的rowid，当你把某个列定义为INTEGER PRIMARY KEY时，这个列就会成为rowid的别名，从而自动获得“插入NULL时分配一个自增整数值”的能力。也就是说，即使不加AUTOINCREMENT，SQLite的主键同样能自增，只不过这种自增在某些边界条件下会复用已经删除的rowid。理解这一点，是正确使用AUTOINCREMENT的前提。很多人在建表时习惯性加上它，主要是受到了MySQL语法的影响，却没有意识到SQLite的语义有细微但关键的差别。下面将围绕这个差异展开。
不带AUTOINCREMENT的INTEGER PRIMARY KEY会出现什么行为
先看一张没有使用AUTOINCREMENT的表。SQLite在创建一张普通表时，如果没有WITHOUT ROWID子句，都会自动带有一个隐藏的rowid。当主键列被声明为INTEGER PRIMARY KEY时，这一列就不再单独占用存储，而是直接映射到rowid。插入数据时，如果主键位置传入NULL，SQLite会自动寻找一个可用的整数作为rowid，通常规则是当前最大rowid + 1。如果表是空的，则从1开始。
这里的关键在于“当前最大”，而不是“历史最大”。也就是说，如果当前最大的rowid是3，删除主键为3的那条记录后，表里当前最大rowid变成了2。此时再插入一条不指定主键的记录，SQLite会重新把3作为新记录的rowid分配出去。对于内部关联表或者临时计算表来说，这种复用通常没有影响，甚至有助于减少数字空洞。但如果业务把主键当成不可重复的流水号，就会留下隐患。用一个简单实验可以验证这个行为。
-- 创建不带AUTOINCREMENT的表
CREATE TABLE orders_no_auto (
id INTEGER PRIMARY KEY,
order_no TEXT NOT NULL,
created_at TEXT DEFAULT (datetime('now'))
);
-- 连续插入三行
INSERT INTO orders_no_auto (order_no) VALUES ('A001');
INSERT INTO orders_no_auto (order_no) VALUES ('A002');
INSERT INTO orders_no_auto (order_no) VALUES ('A003');
-- 查询id与rowid
SELECT id, rowid, order_no FROM orders_no_auto;
-- 删除id为3的行
DELETE FROM orders_no_auto WHERE id = 3;
-- 再次插入，观察新分配的id
INSERT INTO orders_no_auto (order_no) VALUES ('A004');
SELECT id, order_no FROM orders_no_auto;
执行上面最后一组查询时，会看到新插入的id并非很多人以为的4，而是3。这个结果说明，没有AUTOINCREMENT约束时，主键的自增只取决于当前表内最大的rowid，一旦最大行被删除，其编号就可能被后面的插入重新使用。从存储角度看，这没有任何错误；但从业务角度看，如果系统曾经使用过3这个ID，它就可能在数据库里两次指向不同的数据。
AUTOINCREMENT到底在底层多做了什么
加上AUTOINCREMENT以后，建表语句变成id INTEGER PRIMARY KEY AUTOINCREMENT。此时SQLite不仅把主键列映射为rowid，还会在数据库文件中额外维护一张名为sqlite_sequence的系统表。这张表只有两个字段：name和seq，分别记录哪些表启用了AUTOINCREMENT，以及该表曾经出现过的最大rowid值。
sqlite_sequence的作用是让SQLite在分配新rowid时不再只看当前最大rowid，而是比较当前最大rowid与历史记录中的seq，取其中较大的一个再加1。因此，即使把当前最大的行删掉，只要sqlite_sequence里的历史值还留着，下一次插入也不会复用旧编号。换句话说，AUTOINCREMENT的语义是“保证曾经出现过的rowid不会被再次使用”，而不仅仅是“让主键自动增长”。
下面同样用建表、删除、再插入的流程验证。为了观察内部状态，还可以直接查询sqlite_sequence表。注意刚创建空白数据库时这张表并不存在，只有第一次创建带AUTOINCREMENT的表后，SQLite才会自动生成它。
-- 创建带AUTOINCREMENT的表
CREATE TABLE orders_with_auto (
id INTEGER PRIMARY KEY AUTOINCREMENT,
order_no TEXT NOT NULL
);
INSERT INTO orders_with_auto (order_no) VALUES ('B001');
INSERT INTO orders_with_auto (order_no) VALUES ('B002');
INSERT INTO orders_with_auto (order_no) VALUES ('B003');
-- 查看历史最大rowid
SELECT name, seq FROM sqlite_sequence WHERE name = 'orders_with_auto';
-- 此时seq为3
DELETE FROM orders_with_auto WHERE id = 3;
-- 再次插入
INSERT INTO orders_with_auto (order_no) VALUES ('B004');
SELECT id, order_no FROM orders_with_auto;
-- 新插入的记录id为4，不会复用3
从结果可以看出，加与不加AUTOINCREMENT的区别在删除最大主键后体现得最明显。需要注意的是，AUTOINCREMENT只能防止编号被重新使用，不能保证编号一定连续。比如插入一条id为100的记录后，虽然连续插入可能从101继续，但如果事务回滚、行被删除，编号仍然会留下空洞。这一点在业务设计时必须预留预期。
性能开销与写放大问题
既然AUTOINCREMENT只是多维护一张sqlite_sequence表，为什么SQLite官方文档并不鼓励在所有场景下使用它？原因在于每次插入数据时，数据库不仅要写业务表的数据页，还要更新sqlite_sequence表中的对应行。这个更新动作发生在插入路径上，会带来额外的B-Tree查找、页修改和锁竞争。对于单条插入来说，开销或许可以忽略，但在批量插入或高频写入场景中，写放大效应会逐渐显现。
尤其是在一张启用了AUTOINCREMENT的大表里，sqlite_sequence中只有一行记录，却可能被大量并发插入反复更新。SQLite的写锁粒度是数据库级别的，更新这一行同样会参与写事务。如果应用程序主要依靠批量导入来灌数据，可以考虑在导入完成后，再通过ALTER TABLE或重建表的方式决定是否保留AUTOINCREMENT。但更常见的做法是，只有那些真正需要防复用语义的表才启用它，其余表直接使用INTEGER PRIMARY KEY即可。
性能差异还可以从自增分配算法上理解。不加AUTOINCREMENT时，SQLite只需要读取当前表最大rowid，这通常可以通过索引快速确定；而加了AUTOINCREMENT后，需要查询sqlite_sequence表，再更新其中的seq。两次操作叠加后，写入路径明显更长。因此，如果一个应用有大量内部临时表、分片表或中间结果表，认真考虑是否值得为它们启用AUTOINCREMENT，是优化写入性能的重要一步。
正确使用场景与常见误区
判断一张表是否需要AUTOINCREMENT，核心标准只有一个：主键值是否曾经对外暴露，或者业务上是否要求历史ID永远不被复用。典型的需要使用场景包括订单表、流水表、审计日志表等，这些表的主键可能被用户看到、被外部系统引用，或者被用于法律合规审计。一旦删除某条订单后，旧订单号又被分配给新订单，业务层面就会产生严重歧义。
相比之下，大量内部关联表完全不需要防复用能力。比如博客系统中文章与标签的关联表、电商里的购物车临时表、ETL过程中的中间结果表，它们的主键往往只服务于内部查询，对连续性、复用性没有要求。此时省略AUTOINCREMENT不仅少维护一张系统表，还能减少写放大，是更合理的做法。
下面这些常见误区也值得留意。第一，以为主键自增必须加AUTOINCREMENT，实际上INTEGER PRIMARY KEY已经能完成绝大多数自增需求。第二，以为加了AUTOINCREMENT后主键一定连续，实际上事务回滚、删除都可能留下空洞。第三，以为AUTOINCREMENT能加快查询速度，它对读取没有帮助，反而可能影响写入。第四，以为它可以阻止主键被手动更新，实际上只要业务代码执行UPDATE，普通主键和AUTOINCREMENT主键都可能被改成一个新值，前提是不违反唯一约束。理清这些差异以后，选择就变得简单：只在需要防止编号复用时使用，否则就省略。
SQLite自增主键AUTOINCREMENTINTEGER PRIMARY KEY修改时间：2026-10-04 00:36:32