可通过 pg_get_serial_sequence('table', 'column') 查询 GENERATED ALWAYS AS IDENTITY 列的序列名，如 SELECT pg_get_serial_sequence('users', 'id'); 返回 users_id_seq；注意参数为单引号字符串且大小写敏感。
GENERATED ALWAYS AS IDENTITY 列的序列名怎么查？
PostgreSQL 为 GENERATED ALWAYS AS IDENTITY 列自动创建一个关联序列，但序列名不直观——它由系统生成，格式通常是 table_name_column_name_seq。直接查 pg_sequences 可能漏掉，因为该视图默认只显示“用户显式创建”的序列；更可靠的方式是通过 pg_get_serial_sequence() 函数：
SELECT pg_get_serial_sequence('users', 'id');
返回类似 users_id_seq 的结果。注意参数必须是字符串字面量（带单引号），且表名/列名大小写敏感（若建表时加了双引号，这里也得匹配）。
RESET 和 RESTART 的区别：为什么 ALTER SEQUENCE RESTART 不总生效？
对 identity 列的序列执行 ALTER SEQUENCE ... RESTART 后，下一次 INSERT 仍可能跳过你设的值——这是因为 PostgreSQL 在 identity 列上启用了“序列缓存”（cache 默认为 1），且 RESTART 仅重置序列的“当前值”，不重置其内部状态（如已预分配的缓存值）。真正可靠的重置方式是：
ALTER SEQUENCE users_id_seq RESTART WITH 1;- 紧接着执行
SELECT setval('users_id_seq', 1, false);—— 第三个参数false表示“下次调用nextval()就返回 1”，绕过缓存干扰
如果跳过 setval()，而只靠 RESTART，在高并发或刚插入过数据的场景下，新插入的 ID 仍可能从 2 或更高开始。
TRUNCATE … RESTART IDENTITY 能否安全用于生产环境？
可以，但有隐含行为：它不仅清空表，还会调用 ALTER SEQUENCE ... RESTART 重置所有关联 identity 序列，并且会 忽略序列的 OWNED BY 关系，直接操作底层序列对象。这意味着：
- 它比手动
TRUNCATE+ALTER SEQUENCE更简洁 - 但如果该序列被多个表共享（极少见，但技术上可能），
RESTART IDENTITY会一并重置——这不是 bug，是设计如此 - 它不会重建索引或触发器，只影响数据和序列值
执行前建议先确认序列归属：SELECT seqname, schemaname FROM pg_sequences WHERE schemaname = 'public' AND seqname LIKE '%users%';，避免误操作其他表的序列。
identity 列和 SERIAL 的序列行为差异在哪？
核心区别不在序列本身，而在“谁控制调用”：
-
SERIAL是语法糖，本质是INTEGER DEFAULT nextval('seq')，应用或用户仍可显式插入任意整数（包括NULL或重复值） -
GENERATED ALWAYS AS IDENTITY是强制约束，任何显式插入非DEFAULT值都会报错：ERROR: column "id" is an identity column defined as GENERATED ALWAYS
因此，重置序列后，SERIAL 表允许手工插 id=1 来“占位”，而 identity 表不行——必须依赖 nextval() 分配，这也意味着你永远不能假设“重置到 1 后第一个 INSERT 就一定是 1”，除非同时禁用缓存或用 setval(..., false) 精确控制。
