排查mysql函数错误应先看error提示，再查定义合规性、调用参数与环境、权限及调试变量。需关注错误码1415/1305/1418，确保returns类型明确、无select结果集、声明deterministic、带库名前缀调用，并验证sql_mode与execute权限。
看错误信息，别跳过 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; 结果一起贴出来对照，省掉一半弯路。
