函数必须返回值，且只能嵌入 SQL 表达式中调用
MySQL 函数本质是“计算型工具”，定义时必须声明
RETURNS类型（如
INT、
VARCHAR(50)），且必须用
RETURN返回一个标量值。它不能 standalone 执行，只能出现在
SELECT、
WHERE、
ORDER BY等上下文中，比如：
SELECT name, my_tax_calc(salary) AS tax FROM employees;
常见错误是试图用
CALL my_function()调用——这会直接报错
ERROR 1305 (42000): FUNCTION xxx does not exist，因为函数不支持
CALL语法。
函数只允许
IN参数，不能通过参数传出结果；也不能在函数体内执行
INSERT、
UPDATE、
DELETE（MySQL 严格模式下会拒绝创建）。
存储过程用 CALL 执行，能做事务、循环和多结果集输出
存储过程是“操作型容器”，没有返回值概念，但可通过
OUT或
INOUT参数传回多个值，甚至用多个
SELECT语句返回多个结果集。它必须用
CALL显式触发：
CALL transfer_money(1001, 1002, 500.00, @result);
典型适用场景包括：跨表更新+日志记录+异常回滚。例如转账逻辑里，你可以在一个存储过程中完成
UPDATE accounts、
INSERT INTO logs、
IF ... THEN ROLLBACK全流程。
注意：存储过程内部可以安全调用函数，但函数里绝对不能调用存储过程——MySQL 解析器会在创建阶段就报错
ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。
参数类型差异直接影响数据交换能力
这是最常被忽略的实操分水岭：
• 函数：仅支持
IN参数，所有输入都是只读副本，改了也没用；
• 存储过程：支持三种：
–
IN：传入值（默认）
–
OUT：过程内赋值，调用后可读取（如
CALL calc_total(100, @sum); SELECT @sum;）
–
INOUT：既传入又可被修改返回
这意味着，如果你需要“一次调用，拿到金额、状态、错误码三个结果”，函数做不到，必须用存储过程 + 三个
OUT参数。
函数不能改数据，存储过程可以——但别滥用
MySQL 对函数的数据修改权限做了硬性限制：函数体中禁止出现
INSERT、
UPDATE、
DELETE、
DROP等语句（除非显式设置
sql_safe_updates=OFF且用低权限账户，极不推荐）。而存储过程默认放开这些权限。
但反过来说，这也带来风险：一个被误用的存储过程可能悄悄删掉整张表；而函数因天生受限，反而更“安全”——适合放在报表查询中反复使用。
所以实际选型时，别只看“能不能做”，要看“该不该做”：计算字段用函数，封装业务动作用存储过程。 函数的返回值约束和调用位置绑定太紧，存储过程的参数灵活性和流程控制能力太强——这两个特性不是互补，而是分工明确。真正容易出问题的地方，往往不是语法写错，而是把本该用存储过程封装的转账逻辑，硬塞进函数里，结果卡在不能写
UPDATE这一步，再怎么查文档也绕不出来。
