PostgreSQL中使用Sequence而非直接插入获取生成ID有何优势？

1. 提前获取ID，无需等待插入完成 #

很多业务场景下，你需要在插入主表记录前就拿到要使用的ID——比如关联子表记录、生成外部系统需要的唯一标识，或是做前置业务逻辑校验。直接调用nextval('seq_name')就能拿到ID，不用先插入再通过RETURNING或lastval()获取。
示例：

-- 先获取ID
SELECT nextval('user_id_seq') INTO new_user_id;
-- 用该ID插入子表
INSERT INTO user_settings(user_id, theme) VALUES(new_user_id, 'dark');
-- 再插入主表
INSERT INTO users(id, name) VALUES(new_user_id, 'Alice');

这种场景下，若等插入主表再拿ID，必须用事务包裹两次操作，反而增加复杂度。

2. 跨表共享全局唯一ID #

如果业务要求多个表使用同一套全局唯一ID（比如所有业务实体共用ID空间），直接用Sequence可以让多表共享同一个序列，无需给每个表单独创建serial/identity列。比如订单表和支付表共用global_biz_id_seq，能保证全业务线记录ID不重复。

3. 更灵活的序列配置与控制 #

直接操作Sequence可以自定义步长、起始值、缓存大小，甚至手动重置序列值——这些操作在使用serial/identity列时虽也能实现，但直接用Sequence更直观，无需绕到表列属性中调整。
比如设置序列缓存提升高并发性能：

ALTER SEQUENCE user_id_seq CACHE 100;

或者手动重置序列到指定值：

SELECT setval('user_id_seq', 1000);

4. 避免隐式依赖导致的意外删除 #

serial列会自动创建绑定的Sequence，但默认情况下，若删除该列，对应的Sequence也会被一并删除。而手动创建的Sequence是独立对象，不会因表结构变更被意外删除，更适合长期稳定的全局序列场景。

5. 适配复杂业务逻辑需求 #

部分场景需要手动控制ID生成时机：比如批量生成一批ID预留给后续使用，或是分布式系统中给每个节点分配一段Sequence值（减少跨节点序列调用冲突）。直接使用Sequence可以灵活实现这些需求，而依赖表自动生成ID做不到这种粒度的控制。

至于“为何不直接让RDBMS自动生成ID”：其实大部分简单场景下，用serial/identity完全够用，插入后通过RETURNING id就能拿到ID。但当你遇到上述需要提前获取ID、跨表共享、灵活控制的场景时，直接使用Sequence能给你更多控制权，而非完全依赖RDBMS的隐式处理。

内容的提问来源于stack exchange，提问作者J.J. Beam