文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载导读PostgreSQL 的事务保证让回滚后一切仿佛从未发生成为可能这是在生产环境对重要UPDATE或批量写入做预演dry-run的底气所在。但回滚并非完全没有副作用以序列sequence为依托的自增主键即使事务被ROLLBACK其last_value也会永久向前推进留下可见的痕迹。本文基于仓库中 postgres/sequence-side-effect-when-rolling-back-inserts.md 的完整演示逐步验证这一行为剖析其背后的并发设计原因并给出高吞吐场景下的应对方案bigserial、identity column 与 UUID。事务回滚的零副作用预期与序列例外PostgreSQL 最强大的能力之一就是在一个事务内进行大大小小的各种变更然后整体回滚仿佛什么都没发生过。这在生产环境中极其实用想对一个关键的UPDATE语句做干跑验证时可以在事务内执行、检查受影响行数、查看表状态确认无误后再ROLLBACK——数据层面看起来与执行前完全一致。然而回滚即无事发生并非绝对真理。序列sequence就是那个会留下痕迹的例外。每向一张带有自增序列主键的表INSERT一行都会对序列产生一次推进即使这个事务随后被回滚序列的推进也不会撤销。本仓库的 sequence-side-effect-when-rolling-back-inserts.md 用一个books表的完整示例精确复现了这一过程。完整复现插入前、事务内、回滚后的序列状态对比第一步建表并检查序列初始状态首先创建一张使用bigserial自增主键的新表然后直接查看它背后的序列 create table books (id bigserial primary key, title text not null, author text not null); CREATE TABLE select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 1 │ 0 │ f │ └────────────┴─────────┴───────────┘ (1 row)序列以books_id_seq命名命名规则基于表名 列名 _seq。初始状态下last_value为1、log_cnt为0、is_called为ffalse表示尚未真正调用过。仓库中 renaming-a-sequence.md 也印证了这一点serial列会自动创建同名序列重命名表不会自动重命名序列需要手动ALTER SEQUENCE ... RENAME TO ...保持命名一致。第二步开启事务插入三行并再次检查序列 begin; BEGIN insert into books (title, author) values (Python in a Nutshell, Martelli et al), (Build an LLM, Sebastian Raschka), (The Joy of Abstraction, Eugenia Cheng); INSERT 0 3 select * from books; ┌────┬────────────────────────┬───────────────────┐ │ id │ title │ author │ ├────┼────────────────────────┼───────────────────┤ │ 1 │ Python in a Nutshell │ Martelli et al │ │ 2 │ Build an LLM │ Sebastian Raschka │ │ 3 │ The Joy of Abstraction │ Eugenia Cheng │ └────┴────────────────────────┴───────────────────┘ (3 rows) select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 3 │ 30 │ t │ └────────────┴─────────┴───────────┘ (1 row)三条新行的id分别是1、2、3序列的last_value随之推进到3is_called变为ttrue。值得注意的是log_cnt从0跳到30——这是序列内部为 WAL 日志预留的计数窗口用于减少日志同步频率属于实现细节不是本文关注的重点。第三步回滚事务对比表与序列的状态 rollback; ROLLBACK select * from books; ┌────┬───────┬────────┐ │ id │ title │ author │ ├────┼───────┼────────┤ └────┴───────┴────────┘ (0 rows) select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 3 │ 30 │ t │ └────────────┴─────────┴───────────┘ (1 row)结果一目了然books表已被清空回到 0 行但books_id_seq的last_value仍停留在3。回滚把表数据完整还原了却没有把序列倒带。下一次插入时id会从4开始而不是从1开始。原理剖析序列为何游离于事务隔离之外这个行为并非 bug而是 PostgreSQL 的刻意设计。序列被设计为在事务隔离之外工作同一时刻可能有多个并发事务都需要获取序列值如果让它们互相等待如传统加锁方式自增主键分配会成为高并发写入的瓶颈。因此序列总是可以被即时访问每个事务都能立刻拿到一个独占的值。代价正如 sequence-side-effect-when-rolling-back-inserts.md 所指出的序列的last_value只会单调向前推进marching forward永远不会后退。一旦某个事务回滚它消费掉的序列值就变成了永久空洞gap。因此序列值只保证唯一从不保证连续主键列上出现1、2、4、5这类缺口是正常现象3可能被回滚事务消费也可能被未来某个事务消费PostgreSQL 不回收已分配但未提交的值任何依赖id 必须连续无空洞的业务逻辑例如把 id 当序号展示、按 id 差值估算行数都是错误的假设。补充说明nextval的推进同样不回滚序列缓存值也类似。与序列不同的是普通数据表的行级变更受 MVCC 与 WAL 保护回滚后从任何视角都不可见而序列是全局共享、无版本化的计数器这正是二者行为差异的根源。相关序列管理操作速览理解了回滚不重置序列之后自然会关心如何主动重置序列。仓库中提供了两个直接相关的实践手动重启序列restart-a-sequence.md 展示了在开发/测试环境清空表数据后序列仍然从上次的位置继续递增可用以下命令将其重置回任意值 alter sequence my_table_id_seq restart with 1; ALTER SEQUENCETRUNCATE 时一并重置restarting-sequences-when-truncating-tables.md 指出对带serial主键的表执行TRUNCATE后后续插入会继续从上一次的值递增因为序列没有被重置。解决办法是追加restart identity让 PostgreSQL 自动把关联序列重置回1truncate pokemons, trainers, pokemons_trainers restart identity;序列归属change-the-owner-of-a-sequence.md 展示了在线迁移列类型如int换bigint时序列所有权不会自动转移需要ALTER SEQUENCE cats_id_seq OWNED BY cats.id;否则DROP COLUMN会因依赖报错。这些内容都与序列生命周期息息相关可作为本文主题的延伸阅读。高吞吐场景下的应对bigint、identity column 与 UUID原文明确指出这是正常且符合预期的行为但如果你维护的是高吞吐系统——持续大量插入并频繁回滚作者本人就维护过这样的系统——序列值的快速流失值得警惕。最直接的缓解手段是为序列支撑的列选择bigintbigserial。仓库中的 integers-in-postgres.md 详细列出了三种整数类型的容量类型字节范围smallintint22-32768 32767integerint44-2147483648 2147483647bigintint88-9223372036854775808 9223372036854775807bigint的上限约为 9.2×10¹⁸足以在大量插入 频繁回滚的组合下让跑完序列值这个担忧变得不再现实。原文即采用bigserial定义books.id演示与结论在bigint尺度下依旧成立。另一条路径是改用 UUID 作为主键彻底摆脱对序列的依赖也就自然不存在序列值被回滚事务消费的问题。仓库中的 generate-a-uuid.md 与 generating-uuids-with-pgcrypto.md 提供了两种生成方式可在建表时用 UUID 直接代替自增整数主键。最后对于新项目还可以关注现代做法PostgreSQL 官方 wiki 已明确建议Dont use serial转而使用 identity columnGENERATED ... AS IDENTITY。仓库中的 generate-modern-primary-key-columns.md 给出了两种写法的对照——identity column 在 schema、依赖与权限管理上更加规范但它本质上仍由序列驱动同样存在回滚后序列推进的副作用所以本文的核心结论对它依然适用。小结事务回滚能完美还原表数据但不能还原序列ROLLBACK后books_id_seq.last_value仍停留在3这就是序列留在事务隔离之外的代价。序列只保证唯一性不保证连续性id出现空洞是高并发与回滚场景下的正常现象。高吞吐写入 频繁回滚的系统应优先选用bigserialbigint扩大序列容量上限或改用 UUID 主键彻底规避该问题。赞分享文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载相关推荐KeyStore Explorer架构揭秘GUI框架与加密模块深度解析KeyStore Explorer架构揭秘GUI框架与加密模块深度解析 KeyStore Explorer是一款免费的GUI工具可替代Java命令行工具kePostgreSQL 序列重置实战用 ALTER SEQUENCE ... RESTART 精确控制自增主键起点PostgreSQL 序列重置实战用 ALTER SEQUENCE ... RESTART 精确控制自增主键起点 本文聚焦 PostgreSQL 中序列se文档教程知识库SQLDelight JVM PostgreSQL 事务指南transaction / transactionWithResult / Rollback 与回调详解SQLDelight JVM PostgreSQL 事务指南transaction / transactionWithResult / Rollback后端ORM上一篇lcobucci/jwt 令牌验证完全指南assert()、validate() 与全部内置约束详解下一篇Blender 3MF插件专业级3D打印工作流完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载导读PostgreSQL 的事务保证让回滚后一切仿佛从未发生成为可能这是在生产环境对重要UPDATE或批量写入做预演dry-run的底气所在。但回滚并非完全没有副作用以序列sequence为依托的自增主键即使事务被ROLLBACK其last_value也会永久向前推进留下可见的痕迹。本文基于仓库中 postgres/sequence-side-effect-when-rolling-back-inserts.md 的完整演示逐步验证这一行为剖析其背后的并发设计原因并给出高吞吐场景下的应对方案bigserial、identity column 与 UUID。事务回滚的零副作用预期与序列例外PostgreSQL 最强大的能力之一就是在一个事务内进行大大小小的各种变更然后整体回滚仿佛什么都没发生过。这在生产环境中极其实用想对一个关键的UPDATE语句做干跑验证时可以在事务内执行、检查受影响行数、查看表状态确认无误后再ROLLBACK——数据层面看起来与执行前完全一致。然而回滚即无事发生并非绝对真理。序列sequence就是那个会留下痕迹的例外。每向一张带有自增序列主键的表INSERT一行都会对序列产生一次推进即使这个事务随后被回滚序列的推进也不会撤销。本仓库的 sequence-side-effect-when-rolling-back-inserts.md 用一个books表的完整示例精确复现了这一过程。完整复现插入前、事务内、回滚后的序列状态对比第一步建表并检查序列初始状态首先创建一张使用bigserial自增主键的新表然后直接查看它背后的序列 create table books (id bigserial primary key, title text not null, author text not null); CREATE TABLE select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 1 │ 0 │ f │ └────────────┴─────────┴───────────┘ (1 row)序列以books_id_seq命名命名规则基于表名 列名 _seq。初始状态下last_value为1、log_cnt为0、is_called为ffalse表示尚未真正调用过。仓库中 renaming-a-sequence.md 也印证了这一点serial列会自动创建同名序列重命名表不会自动重命名序列需要手动ALTER SEQUENCE ... RENAME TO ...保持命名一致。第二步开启事务插入三行并再次检查序列 begin; BEGIN insert into books (title, author) values (Python in a Nutshell, Martelli et al), (Build an LLM, Sebastian Raschka), (The Joy of Abstraction, Eugenia Cheng); INSERT 0 3 select * from books; ┌────┬────────────────────────┬───────────────────┐ │ id │ title │ author │ ├────┼────────────────────────┼───────────────────┤ │ 1 │ Python in a Nutshell │ Martelli et al │ │ 2 │ Build an LLM │ Sebastian Raschka │ │ 3 │ The Joy of Abstraction │ Eugenia Cheng │ └────┴────────────────────────┴───────────────────┘ (3 rows) select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 3 │ 30 │ t │ └────────────┴─────────┴───────────┘ (1 row)三条新行的id分别是1、2、3序列的last_value随之推进到3is_called变为ttrue。值得注意的是log_cnt从0跳到30——这是序列内部为 WAL 日志预留的计数窗口用于减少日志同步频率属于实现细节不是本文关注的重点。第三步回滚事务对比表与序列的状态 rollback; ROLLBACK select * from books; ┌────┬───────┬────────┐ │ id │ title │ author │ ├────┼───────┼────────┤ └────┴───────┴────────┘ (0 rows) select * from books_id_seq; ┌────────────┬─────────┬───────────┐ │ last_value │ log_cnt │ is_called │ ├────────────┼─────────┼───────────┤ │ 3 │ 30 │ t │ └────────────┴─────────┴───────────┘ (1 row)结果一目了然books表已被清空回到 0 行但books_id_seq的last_value仍停留在3。回滚把表数据完整还原了却没有把序列倒带。下一次插入时id会从4开始而不是从1开始。原理剖析序列为何游离于事务隔离之外这个行为并非 bug而是 PostgreSQL 的刻意设计。序列被设计为在事务隔离之外工作同一时刻可能有多个并发事务都需要获取序列值如果让它们互相等待如传统加锁方式自增主键分配会成为高并发写入的瓶颈。因此序列总是可以被即时访问每个事务都能立刻拿到一个独占的值。代价正如 sequence-side-effect-when-rolling-back-inserts.md 所指出的序列的last_value只会单调向前推进marching forward永远不会后退。一旦某个事务回滚它消费掉的序列值就变成了永久空洞gap。因此序列值只保证唯一从不保证连续主键列上出现1、2、4、5这类缺口是正常现象3可能被回滚事务消费也可能被未来某个事务消费PostgreSQL 不回收已分配但未提交的值任何依赖id 必须连续无空洞的业务逻辑例如把 id 当序号展示、按 id 差值估算行数都是错误的假设。补充说明nextval的推进同样不回滚序列缓存值也类似。与序列不同的是普通数据表的行级变更受 MVCC 与 WAL 保护回滚后从任何视角都不可见而序列是全局共享、无版本化的计数器这正是二者行为差异的根源。相关序列管理操作速览理解了回滚不重置序列之后自然会关心如何主动重置序列。仓库中提供了两个直接相关的实践手动重启序列restart-a-sequence.md 展示了在开发/测试环境清空表数据后序列仍然从上次的位置继续递增可用以下命令将其重置回任意值 alter sequence my_table_id_seq restart with 1; ALTER SEQUENCETRUNCATE 时一并重置restarting-sequences-when-truncating-tables.md 指出对带serial主键的表执行TRUNCATE后后续插入会继续从上一次的值递增因为序列没有被重置。解决办法是追加restart identity让 PostgreSQL 自动把关联序列重置回1truncate pokemons, trainers, pokemons_trainers restart identity;序列归属change-the-owner-of-a-sequence.md 展示了在线迁移列类型如int换bigint时序列所有权不会自动转移需要ALTER SEQUENCE cats_id_seq OWNED BY cats.id;否则DROP COLUMN会因依赖报错。这些内容都与序列生命周期息息相关可作为本文主题的延伸阅读。高吞吐场景下的应对bigint、identity column 与 UUID原文明确指出这是正常且符合预期的行为但如果你维护的是高吞吐系统——持续大量插入并频繁回滚作者本人就维护过这样的系统——序列值的快速流失值得警惕。最直接的缓解手段是为序列支撑的列选择bigintbigserial。仓库中的 integers-in-postgres.md 详细列出了三种整数类型的容量类型字节范围smallintint22-32768 32767integerint44-2147483648 2147483647bigintint88-9223372036854775808 9223372036854775807bigint的上限约为 9.2×10¹⁸足以在大量插入 频繁回滚的组合下让跑完序列值这个担忧变得不再现实。原文即采用bigserial定义books.id演示与结论在bigint尺度下依旧成立。另一条路径是改用 UUID 作为主键彻底摆脱对序列的依赖也就自然不存在序列值被回滚事务消费的问题。仓库中的 generate-a-uuid.md 与 generating-uuids-with-pgcrypto.md 提供了两种生成方式可在建表时用 UUID 直接代替自增整数主键。最后对于新项目还可以关注现代做法PostgreSQL 官方 wiki 已明确建议Dont use serial转而使用 identity columnGENERATED ... AS IDENTITY。仓库中的 generate-modern-primary-key-columns.md 给出了两种写法的对照——identity column 在 schema、依赖与权限管理上更加规范但它本质上仍由序列驱动同样存在回滚后序列推进的副作用所以本文的核心结论对它依然适用。小结事务回滚能完美还原表数据但不能还原序列ROLLBACK后books_id_seq.last_value仍停留在3这就是序列留在事务隔离之外的代价。序列只保证唯一性不保证连续性id出现空洞是高并发与回滚场景下的正常现象。高吞吐写入 频繁回滚的系统应优先选用bigserialbigint扩大序列容量上限或改用 UUID 主键彻底规避该问题。赞分享文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载相关推荐KeyStore Explorer架构揭秘GUI框架与加密模块深度解析KeyStore Explorer架构揭秘GUI框架与加密模块深度解析 KeyStore Explorer是一款免费的GUI工具可替代Java命令行工具kePostgreSQL 序列重置实战用 ALTER SEQUENCE ... RESTART 精确控制自增主键起点PostgreSQL 序列重置实战用 ALTER SEQUENCE ... RESTART 精确控制自增主键起点 本文聚焦 PostgreSQL 中序列se文档教程知识库SQLDelight JVM PostgreSQL 事务指南transaction / transactionWithResult / Rollback 与回调详解SQLDelight JVM PostgreSQL 事务指南transaction / transactionWithResult / Rollback后端ORM上一篇lcobucci/jwt 令牌验证完全指南assert()、validate() 与全部内置约束详解下一篇Blender 3MF插件专业级3D打印工作流完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
