MySQL触发器无法用AUTO_INCREMENT生成带前缀订单号，因其仅支持纯数字、全局递增且须为主键或唯一索引；正确做法是在BEFORE INSERT中手动赋值order_no，并用SELECT ... FOR UPDATE加锁确保并发安全。
MySQL触发器里不能用 AUTO_INCREMENT 生成带前缀的订单号
因为 AUTO_INCREMENT 只支持纯数字、全局递增、且必须是主键或唯一索引列，没法拼前缀（比如 "ORD202405150001"），也不能按业务规则重置（如每天从 0001 开始）。硬塞进自增字段会报错或行为异常。
常见错误现象：ERROR 1362 (HY000): Updating of AUTO_INCREMENT column is not allowed，或者插入时触发器读到的 NEW.id 是 0，导致拼接出 "ORD202405150" 这种残缺编号。
- 必须用
BEFORE INSERT触发器，在写入前手动赋值给订单号字段（比如order_no） - 不能依赖
LAST_INSERT_ID()，它只对AUTO_INCREMENT列有效，而你根本没用它 - 如果需要“每日重置”，得自己查当天最大编号，再 +1；别想靠
ALTER TABLE ... AUTO_INCREMENT = X动态改，不安全也不并发友好
用 SELECT MAX() + WHERE 拼日期前缀时务必加事务和锁
典型场景：订单号格式为 "ORD" + DATE_FORMAT(NOW(), "%Y%m%d") + LPAD(?, 4, "0")，其中 ? 是当天已有的最大序号 +1。但多个并发插入同时执行 SELECT MAX(order_no) FROM orders WHERE order_no LIKE "ORD20240515%"，很可能查到同一个最大值，结果生成重复订单号。
- 必须把触发器逻辑包在
START TRANSACTION里（即触发器本身不能开事务，得在应用层或存储过程里控制） - 更稳妥的做法是：先用
SELECT ... FOR UPDATE锁住当天的“计数行”（推荐单独建一张seq_daily表，每行存一个date和counter） - 避免在触发器里直接查主表
orders，尤其是大表，MAX()+LIKE会全表扫描，慢还锁表
触发器里调用 NOW() 和 CURDATE() 的时区陷阱
NOW() 返回的是 MySQL 服务器当前时区的时间，不是客户端传入时间，也不是 UTC。如果你的应用部署在多个时区，或者数据库开启了 default-time-zone='+08:00' 但应用代码用 UTC 时间生成订单，就会出现“订单号日期比实际下单日早/晚一天”。
- 统一用
CURDATE()而不是DATE(NOW())，前者语义明确且不受时分秒干扰 - 如果业务要求“按用户本地时间生成订单号”，别在触发器里处理——触发器看不到 HTTP 请求头或用户时区，这事得在应用层做
- 检查
SELECT @@global.time_zone, @@session.time_zone，确保和你的业务预期一致，否则"ORD20240515"可能变成"ORD20240514"
替代方案：为什么更推荐用应用层生成 + 唯一索引兜底
触发器生成订单号看似“全自动”，但调试难、测试难、迁移难，一旦逻辑出错，所有插入都卡死或写脏数据。真正线上稳定的做法，是让应用自己算好 order_no，然后靠数据库唯一约束保底。
- 应用生成：用当前日期 + Redis INCR 或数据库独立计数表取当日序号，拼成
order_no - 数据库加
UNIQUE KEY (order_no)，万一生成重复（极小概率），就捕获ERROR 1062 (23000): Duplicate entry重试一次 - 彻底避开触发器的隐式执行时机问题（比如复制环境、延迟从库上触发器不执行）
复杂点在于你要自己管好计数器的原子性和重置逻辑，但比在触发器里写一堆 SELECT ... FOR UPDATE 更可控、更易测、也更容易水平扩展。
