MAX(id) + 1 在并发下会生成重复流水号，因多个事务同时读取相同最大值后加1插入，形成“读-改-写”竞态；数据库对 MAX() 默认快照读不加锁，无法保证原子性。
为什么 MAX(id) + 1 在并发下会生成重复流水号
直接用 SELECT MAX(id) + 1 FROM orders 获取下一个流水号，看似简单，但在多事务同时执行时，两个事务可能在同一时刻读到相同的 MAX(id) 值，各自加 1 后插入相同 ID —— 这是典型的“读-改-写”竞态。数据库不会自动给这个查询加写锁，MAX() 只是快照读（尤其在 RR 隔离级别下），不阻塞其他读。
用 SELECT ... FOR UPDATE 锁住 MAX 结果行
在支持行级锁的数据库（如 MySQL InnoDB、PostgreSQL）中，可以先查出当前最大值，并显式加锁，再插入。关键不是锁住 MAX() 函数本身（它没对应行），而是锁住能代表“最新流水”的某一行（比如最后一条记录）或专用控制表。
- 推荐做法：建一张
seq_table，只有一行，含current_value字段，每次用SELECT current_value FROM seq_table FOR UPDATE读取并锁住该行 - 接着执行
UPDATE seq_table SET current_value = current_value + 1（原子性保证） - 应用层拿到旧值后拼流水号，例如
'ORD' || LPAD(1001, 6, '0') - 注意：必须在同一个事务里完成
SELECT ... FOR UPDATE→UPDATE→ 应用处理 →INSERT，否则锁释放后仍可能被插队
更可靠：用数据库原生序列或自增主键 + 映射表
靠 MAX() 模拟序列本质是绕过数据库的并发控制机制，风险高、性能差（全表扫描）、且无法跨分库伸缩。真正稳定的方案是交由数据库自己管理递增值：
- MySQL：用
AUTO_INCREMENT主键，再通过触发器或应用层格式化为业务号（如ORD000123），避免在业务逻辑里算 ID - PostgreSQL：直接用
CREATE SEQUENCE，配合NEXTVAL()，它天然线程安全、无锁等待、可缓存 - 如果必须按业务规则重排（如每月重置），用复合键控制表：
INSERT INTO seq_monthly (year_month, next_val) VALUES ('202405', 1) ON CONFLICT ... DO UPDATE SET next_val = seq_monthly.next_val + 1 RETURNING next_val（PostgreSQL）
警惕隐式类型转换和 NULL 边界问题
MAX() 遇到全空表返回 NULL，NULL + 1 还是 NULL，直接导致插入失败或默认值覆盖；字符串前缀拼接时若没补零，LPAD() 参数错位也会让 12 变成 '000012' 而不是预期的 '0000012'。
- 务必用
COALESCE(MAX(id), 0) + 1处理空表场景 - 检查字段类型：如果
id是字符串（如'ORD000123'），MAX()比较的是字典序，'ORD0002'>'ORD000123'，结果错误 - 不要在 WHERE 条件里对流水号字段用函数（如
WHERE SUBSTR(no, 4) > '1000'），会导致索引失效
真正安全的流水号生成，从来不是靠应用层算 MAX() + 1，而是把递增逻辑下沉到数据库原子操作层——否则你锁的不是数据，是自己的头发。
