SQLAlchemy autoincrement自增ID插入跳号（ID从5跳到151）如何排查修复

产生原因 #

• 数据库序列缓存机制：PostgreSQL、Oracle等支持序列预缓存的数据库，会为序列设置cache参数，提前为每个会话分配一批连续ID，会话结束后未使用的ID会被直接丢弃。你遇到的从5跳到151的情况，大概率是序列缓存值设为150，第一次会话用了前5个，剩下的145个随会话关闭被丢弃，新会话就从151开始分配。MySQL如果开启innodb_autoinc_lock_mode = 2，批量插入回滚时已分配的自增ID也不会回收，同样会出现跳号。
• 事务回滚：自增ID/序列的分配逻辑不随事务回滚，只要执行过插入操作，哪怕事务最终回滚，已经分配的ID也不会被回收，后续插入会直接使用新的ID。
• SQLAlchemy批量操作预分配ID：调用bulk_save_objects、bulk_insert_mappings这类批量写入API时，SQLAlchemy会提前预分配一批连续ID，如果实际插入的数据量小于预分配量，未使用的ID会被直接浪费，导致后续插入跳号。
• 手动指定ID插入：如果有操作手动插入过ID为150的记录，后续自增序列也会自动从151开始分配。

修复方案 #

注意：自增ID的设计目标是保证唯一且递增，本身就不承诺连续性，如果业务不依赖ID连续，完全不需要处理跳号问题，不会影响数据正确性。
如果确实需要尽可能保证ID连续，可按以下方案处理：

• 调整数据库序列缓存参数：将对应表的自增序列缓存值设为1，避免预缓存丢弃导致的跳号，该操作会小幅度降低高并发插入性能。以PostgreSQL为例，执行命令：ALTER SEQUENCE customer_id_seq CACHE 1;
• 优化业务逻辑减少回滚：梳理插入相关的业务代码，减少不必要的插入事务回滚，避免无效ID被分配。
• 调整SQLAlchemy批量操作逻辑：如果是批量API导致的跳号，可给bulk_insert_mappings传入preserve_order=True参数，或使用session.add_all()替代批量写入API，该调整会小幅度降低批量写入性能。
• 重置序列（仅适用于开发测试环境）：如果是测试阶段无重要业务数据，可将序列重置到当前表的最大ID之后，后续就会从连续ID开始分配。以PostgreSQL为例，执行命令：SELECT setval('customer_id_seq', (SELECT MAX(id) FROM customer));

内容的提问来源于stack exchange，提问作者Fasil K