能实现全局唯一业务ID，但需在触发器中用pg_advisory_xact_lock或LOCK控制并发，先取NEXTVAL再TO_CHAR+LPAD拼接前缀，避免应用层拼接破坏原子性，跨库时SEQUENCE失效。

PostgreSQL 中用 SEQUENCE + TRIGGER 生成全局唯一业务 ID 的核心逻辑

直接说结论：能实现，但「全局唯一」不等于「业务友好」——SEQUENCE 本身只保证单调递增和跨事务不重复，若要带业务前缀（如 "ORD2024051700001"）、时间信息或分片标识，必须在触发器里拼接并校验长度、格式、冲突风险。

触发器里怎么安全拼接前缀 + 序列值

常见错误是直接用 NEXTVAL('seq_name') 拼字符串后赋给字段，结果并发插入时出现重复 ID（因为触发器执行顺序不可控，且序列跳号不等于业务编号连续）。

• 必须用 pg_advisory_xact_lock() 或表级 LOCK TABLE ... IN EXCLUSIVE MODE 控制并发拼号节奏（仅在极低频、强顺序要求场景才需）
• 更推荐：先取 NEXTVAL，再用 TO_CHAR 格式化为固定位数，最后拼前缀，例如：

  NEW.id := 'ORD' || TO_CHAR(CURRENT_DATE, 'YYYYMMDD') || LPAD(NEXTVAL('order_id_seq')::TEXT, 5, '0');

• 注意 LPAD 位数要大于序列最大预期值位数，否则溢出截断（比如设 5 位但序列已到 100000）

为什么不能在应用层做拼接

看似简单，但会破坏原子性：应用取序列值 → 拼接 → 插入，中间若失败或重试，可能漏号、重复、或生成非法格式 ID（如日期错位、前缀写死未更新）。

Yyds.Auto

通过MCP控制Android设备——点击、滑动、OCR、截图、UI自动化、Shell、文件管理及AI代理编排，实现Android RPA。

下载

• 触发器在 DB 层闭环，确保每次 INSERT 都经过同一套规则
• 序列值由 DB 分配，不受网络延迟、应用重启、多实例竞争影响
• 但代价是：无法在插入前预知 ID（比如要存入关联日志或消息队列），得改用 RETURNING id 获取

容易被忽略的边界问题

实际跑通不难，真正踩坑多在细节：

• SEQUENCE 的 START WITH 和 INCREMENT BY 要匹配业务增长预期；比如日均 10 万单，用 INCREMENT BY 1 没问题，但若用 BY 100 就会大量跳号
• 触发器函数必须定义为 BEFORE INSERT，且 WHEN (NEW.id IS NULL) 避免覆盖手动传入的 ID
• 如果业务 ID 后续要用于分区键或索引前导列，注意字符串长度是否超出索引限制（如 CHAR(20) vs TEXT）
• 备份恢复后，别忘了用 SELECT SETVAL('seq_name', ...) 同步序列当前值，否则新插入可能撞号

最麻烦的其实是「全局」二字——跨库、跨集群时 SEQUENCE 天然失效，这时得换 Snowflake、Redis 自增或数据库代理层统一分发。单库场景下，这套组合够用，但别把它当分布式 ID 方案用。