SQL Server需用usp_GetSysid配合配置表实现带前缀自增编号，必须显式加XLOCK锁并在同一事务内完成读值、拼接、更新；MySQL 5.7用单行表+FOR UPDATE模拟序列；PostgreSQL用原生SEQUENCE配to_char()，注意NEXTVAL不可回滚。
SQL Server 用 usp_GetSysid 实现带前缀的自增编号
直接复用系统 IDENTITY 或 AUTO_INCREMENT 无法满足业务编号规则（如 ORD2026060001），必须靠独立计数器+格式化拼接。SQL Server 常见做法是建一张配置表（如 sys_number），按前缀隔离计数，避免跨类型冲突。
关键点在于锁和事务边界：
-
SELECT ... WITH (XLOCK)必须显式加锁，否则并发调用会读到相同value - 整个「读值 → 拼接 → 更新」必须包在同一个
BEGIN TRAN内，否则中间失败会导致号段空缺 - 前缀建议用业务标识（如
'ORD202606'）而非纯类型名（如'ORD'），否则每月需手动重置或加日期判断逻辑
MySQL 5.7 用单行锁表模拟 SEQUENCE
MySQL 5.7 没有原生 SEQUENCE，但可用单行表 + SELECT ... FOR UPDATE 模拟，这是最稳妥的兼容方案。
示例结构：
CREATE TABLE seq_generator (
name VARCHAR(50) PRIMARY KEY,
next_val BIGINT NOT NULL
);
INSERT INTO seq_generator VALUES ('order_no', 1);
存储过程中必须：
- 显式写
START TRANSACTION，否则FOR UPDATE在自动提交模式下无效 - 用
LPAD(cur_val, 4, '0')补零，别用cur_val + 10000这类 trick——溢出时会崩成负数或科学计数法 - 拼接时用
DATE_FORMAT(NOW(), '%Y%m')而非CONCAT(YEAR(NOW()), LPAD(MONTH(NOW()),2,'0'))，前者原子性更好且少一次函数调用
PostgreSQL 用原生 SEQUENCE 配合 to_char()
PostgreSQL 的 NEXTVAL 是无锁、高性能的，但要注意它不可回滚——一旦取号，即使事务 rollback，该号也已消耗。
所以逻辑顺序不能错：
- 先确认业务记录要插入（比如校验通过、状态合法），再调
NEXTVAL - 格式化必须在数据库内完成，避免应用层拼接后网络中断导致号丢失
-
to_char(nextval('order_seq'), 'FM000000')中的FM修饰符去掉前导空格，否则补零失效 - 不要把
NEXTVAL放在INSERT ... SELECT里批量取号——可能因并行执行顺序导致乱序
所有方案都绕不开的硬约束
无论用哪种数据库，只要编号用于关键业务（如订单、合同），就必须保证「获取号段 → 格式化 → 写入业务表」三步原子性。常见错误是：存储过程只返回编号，由应用层决定是否插入；一旦应用崩溃或网络断开，号就永久空缺。
另一个容易被忽略的点是位数上限——比如用 LPAD(..., 4, '0')，当流水号超过 9999 时不会自动进位，而是截断或报错。实际部署前必须压测并发峰值，并预留至少 20% 余量。
