看错误信息，别跳过 ERROR 提示
MySQL 函数执行失败时，第一反应不是重写函数，而是看它报了什么错——错误码和消息直接指向根因。
ERROR 1415（Not allowed to return a result set from a function）说明你写了
SELECT * FROM t;这类语句；
ERROR 1305（FUNCTION xxx does not exist）说明调用名写错了或函数根本没创建成功；
ERROR 1418（This function has none of DETERMINISTIC…）则暴露了函数定义缺声明。 立刻执行
SHOW ERRORS;查最近一次错误详情 确认调用是否带库名前缀：
SELECT mydb.my_func();而非仅
SELECT my_func();（尤其跨库或函数在非默认库时） 用
SHOW FUNCTION STATUS LIKE 'my_func';验证函数是否存在、状态是否为
YES
检查函数定义是否“合规”，不是“能跑就行”
MySQL 对函数体的限制比存储过程严格得多：它不允许返回结果集、强制要求声明确定性、还卡 SQL 数据访问权限。很多“本地测试能跑”的函数一上线就失败，就是因为定义漏了关键子句。
必须有RETURNS+ 明确类型，比如
RETURNS INT，不能写
RETURNS INTEGER（虽部分版本兼容，但不推荐） 函数体内禁止出现无
INTO的
SELECT，例如
SELECT col FROM t;是非法的；正确写法是
SELECT col INTO @var FROM t;必须显式声明
DETERMINISTIC或
NOT DETERMINISTIC；若读数据，还得加
READS SQL DATA用
SHOW CREATE FUNCTION my_func;拿到当前定义，逐行核对有没有拼错
BEGIN/
END、漏
DELIMITER或多空格导致解析失败
验证调用参数和运行环境，别让类型“悄悄变形”
函数定义是
INT，你传了字符串
'5'，MySQL 可能隐式转换但触发警告甚至报错（尤其在严格
sql_mode下）；或者函数里用了
CONNECTION_ID()这类会话级函数，但在主从复制场景下被拒绝执行。 调用时用
SELECT my_func(5, 10);，而非
SELECT my_func('5', '10'); —— 字符串转数字可能失败或截断
检查当前会话的 sql_mode：执行
SELECT @@sql_mode;，若含
STRICT_TRANS_TABLES或
NO_ENGINE_SUBSTITUTION，需确保所有变量赋值、计算不越界（如除零、溢出） 主从环境中，函数若声明为
MODIFIES SQL DATA且未设
log_bin_trust_function_creators=1，从库会拒绝执行 权限不足也会静默失败：用户需有
EXECUTE权限，不是
SELECT权限——执行
GRANT EXECUTE ON FUNCTION mydb.my_func TO 'user'@'host';
加调试输出，但别用 SELECT —— 改用变量+注释法
函数里不能
SELECT打印中间值，但可以靠变量观察逻辑流。这是最实用、零侵入的排查方式。 在关键节点用
SET @debug = CONCAT('step1: a=', a, ', b=', b); 记录状态
执行完函数后，立即查 SELECT @debug;看走到哪一步、变量值是否符合预期 若函数返回异常值（如
NULL），优先检查所有
DECLARE变量是否初始化，未初始化的
INT默认为
NULL，参与运算易得
NULL复杂逻辑可拆成最小可测单元：先单独测试函数内某条
UPDATE或
SELECT ... INTO是否语法/权限/数据存在性都 OK
真正卡住的地方，往往不是语法错，而是“以为它该这样，其实 MySQL 规定它必须那样”——比如忘了
READS SQL DATA，比如在只读从库上调用写函数，比如用 root 创建的函数却用普通用户去调。每次排查，都建议把
SHOW CREATE FUNCTION输出和
SHOW GRANTS FOR CURRENT_USER;结果一起贴出来对照，省掉一半弯路。
