MySQL函数中无法用DECLARE HANDLER实现优雅降级，唯一可靠方式是主动SIGNAL SQLSTATE '45000'并设MESSAGE_TEXT，由客户端通过SQLSTATE识别处理；函数不支持事务、EXIT HANDLER及稳定异常捕获。
MySQL函数中不能用 DECLARE HANDLER 捕获异常后“优雅降级”，但可以用 SIGNAL 主动中断并返回明确错误——这是唯一可靠、客户端可感知的自定义报错方式。
函数里不能用 DECLARE CONTINUE HANDLER 作“兜底返回”
很多人想写类似“查不到就返回 NULL”的容错逻辑，但 MySQL 函数对异常处理极其受限：DECLARE CONTINUE HANDLER 在函数中虽语法合法，但一旦触发（比如 SELECT ... INTO 查无结果导致 ERROR 1329），函数会直接终止，RETURN 语句不会执行，调用方收到的是原始 SQL 错误，不是你预设的值。
- 函数不支持
EXIT HANDLER或事务控制，无法回滚或重试 -
CONTINUE HANDLER在函数中实际效果不可靠，不同版本行为不一致，官方文档也未保证其在函数中的稳定性 - 试图用
SET @var = NULL+RETURN @var绕过，仍会在 handler 执行前因错误退出
SIGNAL SQLSTATE '45000' 是唯一可控的报错出口
必须在逻辑分支明确处主动抛出，让错误发生在函数执行路径上，而非依赖捕获。客户端（PHP PDO、Python pymysql、Java JDBC）都能拿到 SQLSTATE '45000' 和你写的 MESSAGE_TEXT。
- 必须搭配
SET MESSAGE_TEXT = 'xxx'，否则错误信息为空或为默认乱码 - 不要在
SIGNAL前做全表扫描类操作（如无索引字段的EXISTS），否则性能雪崩 - 示例：防除零
DELIMITER $$
CREATE FUNCTION divide_safe(x DECIMAL(10,2), y DECIMAL(10,2))
RETURNS DECIMAL(10,2)
BEGIN
IF y = 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '除数不能为零';
END IF;
RETURN x / y;
END$$
DELIMITER ;
别把函数当存储过程用：避免隐式错误源
函数被设计为纯计算单元，禁止含修改语句（INSERT/UPDATE）、禁止显式事务、禁止调用非确定性函数（如 NOW()）——这些都会直接报错，且无法用 SIGNAL 覆盖。
- 所有输入参数必须参与确定性计算，否则函数可能被优化器拒绝缓存或报
ERROR 1418 - 若需查表校验（如检查 ID 是否存在），确保目标字段有索引，且用
EXISTS而非SELECT ... INTO - 外键关联失败这类错误（
ERROR 1452）发生在语句执行时，函数里无法预检；应在调用方或触发器层拦截
JDBC/PHP 端要主动识别 45000 才算真正“优雅”
服务端抛了 SIGNAL，客户端不处理仍是裸错。必须在应用层提取 SQLSTATE 或错误码判断。
- JDBC 中用
e.getSQLState().equals("45000")区分业务错误和系统故障 - PHP PDO 需检查
$e->getCode() === '45000'，而非只看$e->getMessage() - 不要依赖错误消息文本做判断（中文可能被编码截断或翻译），
SQLSTATE才是稳定契约
真正难的不是写 SIGNAL，而是把“哪里该抛”想清楚：函数边界必须干净，所有前置校验（空值、范围、存在性）都要在进入计算前完成，否则错误会漏到调用链更上层，失去控制权。
