MySQL 5.7自定义函数不可直接调用NOW()或SELECT MAX()生成订单号，因其违反DETERMINISTIC约束；安全做法是将时间、序号作为参数传入，函数仅负责格式化拼接，生成逻辑须由存储过程或应用层在事务/锁保障下完成。
MySQL 5.7 支持创建自定义函数（FUNCTION），但必须满足 DETERMINISTIC、NO SQL 或 READS SQL DATA 等安全属性，且不能直接调用 NOW()、RAND() 等非确定性函数——这意味着你无法在函数体内“实时生成带时间戳的唯一编号”并保证可重复调用安全。所以，**直接用函数生成「格式化订单流水号」是可行的，但必须把时间、序号等动态部分作为参数传入，不能在函数里自己取当前时间或查最大值。**
为什么不能在函数里用 NOW() 或 SELECT MAX()？
MySQL 5.7 对自定义函数有严格限制：函数必须声明为 DETERMINISTIC（确定性）才能被允许调用，而 NOW() 每次返回不同值，SELECT MAX(order_no) FROM orders 依赖表状态，都属于非确定性操作。如果强行声明为 DETERMINISTIC 却调用非确定性逻辑，MySQL 可能报错 ERROR 1418，或在复制/从库场景下引发不一致。
- 常见错误信息：
ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration - 即使加了
READS SQL DATA，也不能在函数中执行INSERT/UPDATE，也不能用于生成递增序号（因为函数不可修改数据） - 函数适合做「纯计算」，比如拼接、补零、日期格式转换；不适合做「业务编号生成器」这类需读写+状态维护的操作
安全可用的函数写法：只做格式化，不做生成
把「年月日+两位部门码+5位流水」这种逻辑封装成函数是稳妥的，前提是把时间戳和序号作为输入参数。例如：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
DROP FUNCTION IF EXISTS format_order_no;
DELIMITER $$
CREATE FUNCTION format_order_no(
in_date DATE,
in_dept CHAR(2),
in_seq INT
) RETURNS CHAR(16)
READS SQL DATA
DETERMINISTIC
BEGIN
RETURN CONCAT(
DATE_FORMAT(in_date, '%y%m%d'),
in_dept,
LPAD(in_seq, 5, '0')
);
END$$
DELIMITER ;
-
in_date由调用方传入（如CURDATE()），避免函数内调用NOW() -
in_seq必须由应用层或存储过程控制（比如查出当天最大号后 +1），函数只负责补零和拼接 - 返回类型用
CHAR(16)而非VARCHAR，避免隐式转换影响索引或比较 - 不要在函数里写
INSERT INTO ... SELECT MAX(...) + 1—— 这会报错且破坏事务隔离
真正生成唯一流水号，应该在哪做？
函数只是工具，编号生成逻辑必须放在可控、可串行化的上下文中：
- 推荐用存储过程（
PROCEDURE）：支持事务、变量、SELECT ... FOR UPDATE锁行，能安全读取+递增当日序号 - 或者由应用层生成：先
SELECT MAX(order_no) FROM orders WHERE DATE(create_time) = CURDATE()，解析出序号，+1 后调用format_order_no(CURDATE(), '01', new_seq) - 更可靠的做法是建一张
seq_daily表，按date + dept主键存当前最大序号，用INSERT ... ON DUPLICATE KEY UPDATE原子更新，再读出来拼接 - 绝对不要在触发器里调用该函数并试图自动填充字段——触发器中调用含
SELECT的函数可能引发死锁或复制中断
关键点在于：MySQL 函数不是黑盒编号工厂，它只是字符串组装工。把「何时取时间」「如何保证序号不重」「在哪加锁」这些事甩给函数，一定会踩坑。真正的复杂性不在格式化，而在并发下的序号分配逻辑本身。
