能实现全局唯一业务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（如日期错位、前缀写死未更新）。
- 触发器在 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)vsTEXT） - 备份恢复后，别忘了用
SELECT SETVAL('seq_name', ...)同步序列当前值，否则新插入可能撞号
最麻烦的其实是「全局」二字——跨库、跨集群时 SEQUENCE 天然失效，这时得换 Snowflake、Redis 自增或数据库代理层统一分发。单库场景下，这套组合够用，但别把它当分布式 ID 方案用。
