MySQL函数禁止执行UPDATE等DML操作，因其被设计为无副作用的纯计算单元；而存储过程定位为可执行脚本，显式CALL调用允许包含事务和DML。
MySQL 允许在存储过程中执行 UPDATE、INSERT 等 DML 操作，但禁止在函数（FUNCTION）中修改表——这不是权限或配置问题，而是由 SQL 标准和 MySQL 的执行模型共同决定的硬性限制。
为什么函数里写 UPDATE 会直接报错
MySQL 函数被设计为“纯计算单元”，必须满足确定性（deterministic）和无副作用（no side effects）原则。调用函数的地方可能是 SELECT 列表、WHERE 条件、ORDER BY 子句等上下文，这些位置不能触发数据变更。
- 只要函数体里出现
UPDATE、INSERT、DELETE或REPLACE，MySQL 就会在创建时拒绝：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled（开启 binlog 时更严格） - 即使你加了
SQL SECURITY DEFINER并授予足够权限，也绕不过这个语法拦截 - 函数里连
SELECT ... FOR UPDATE都不被允许——它本质是“读+锁”，已属事务性操作
存储过程为什么可以改表
存储过程（PROCEDURE）定位就是“可执行的数据库脚本”，明确允许包含事务控制、DML、DDL 和流程逻辑。它的调用方式是显式的 CALL proc_name()，MySQL 能清晰区分“执行动作”和“计算表达式”。
-
CALL是独立语句，不在任何表达式上下文中，不会破坏查询语义 - 过程内可使用
START TRANSACTION、COMMIT、ROLLBACK，而函数完全不可 - 过程支持
OUT/INOUT参数传递状态，函数只能返回单个值
常见误判：以为加 READS SQL DATA 就能绕过
有人尝试给函数加特性声明来“松绑”，比如：
CREATE FUNCTION f() RETURNS INT READS SQL DATA BEGIN UPDATE t SET x = 1; -- 依然报错 RETURN 1; END;
这没用。READS SQL DATA 只表示“只读取，不修改”，MODIFIES SQL DATA 才允许写，但 MySQL **根本不允许函数声明为 MODIFIES SQL DATA**——该选项只对存储过程开放。
- 函数的合法特性只有：
DETERMINISTIC、NO SQL、READS SQL DATA、CONTAINS SQL - 一旦函数里有写操作，无论怎么声明，创建都会失败
- 试图用动态 SQL（
PREPARE+EXECUTE）也无效，解析阶段就卡死
真要从函数逻辑里触发更新？换思路
如果你的业务场景是“某个字段值依赖另一张表状态，且想在 SELECT 中自动体现”，函数做不到，但有替代路径：
- 用视图（
VIEW）封装JOIN+ 计算逻辑，避免重复写关联条件 - 在应用层做两步：先查函数结果，再根据结果发
UPDATE（注意并发一致性） - 把逻辑下沉到触发器（
BEFORE UPDATE）或事件（EVENT），由外部时机驱动 - 极少数强需求下，改用存储过程 + 应用层
CALL+SELECT分开调用
最易被忽略的一点：函数报错信息里常带 “binary logging is enabled”，但这不是根本原因——即使关掉 binlog，MODIFIES SQL DATA 对函数仍是非法声明。限制来自语义层，不是日志策略。
