MySQL函数禁止修改表数据是设计限制，因其必须纯计算、无副作用；函数仅支持READS SQL DATA或NO SQL，禁用UPDATE/INSERT/DELETE，违者报错1415或1418；替代方案为存储过程、单条UPDATE子查询或应用层SELECT...FOR UPDATE加事务控制。
MySQL函数本身不能修改表数据，这是设计限制，不是bug或配置问题。
为什么函数里写UPDATE会报错
MySQL严格区分函数（FUNCTION）和存储过程（PROCEDURE）的用途：函数必须是“纯计算”的，不能产生副作用。一旦你在函数体里写 UPDATE、INSERT 或 DELETE，MySQL会直接拒绝创建，报错：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled，或者更直白的：ERROR 1415 (0A000): Not allowed to return a result set from a function —— 本质是权限模型层面禁止。
- 函数只能读数据（
READS SQL DATA）或完全不碰表（NO SQL），不能改数据 - 即使加了
MODIFIES SQL DATA声明，也会被拒绝：MySQL不支持可写函数 - 触发器、视图、默认值表达式里也不能调用含写操作的函数
想在查询中“顺带更新”，该用什么
如果你的真实需求是“查完某条记录后立刻更新它”（比如计数+标记已读），函数做不到，但有明确替代路径：
- 用存储过程（
PROCEDURE）封装SELECT+UPDATE逻辑，显式调用 - 用单条
UPDATE ... WHERE ... LIMIT 1配合子查询，例如：UPDATE logs SET status='read' WHERE id = (SELECT id FROM unread_logs LIMIT 1) - 应用层控制：先
SELECT ... FOR UPDATE加行锁，再UPDATE，确保原子性 - 避免“伪原子”陷阱：不要依赖函数返回值去驱动后续更新，这中间可能被其他事务干扰
常见误用场景和坑
很多人试图绕过限制，结果掉进更深的坑：
- 在函数里调用
sys_eval()或自定义UDF（用户定义函数）强行写表 → MySQL 8.0+ 默认禁用，且极度危险，可能崩溃或被远程执行 - 用函数返回SQL字符串，再在应用里拼接执行 → 失去事务边界，无法回滚，易SQL注入
- 在触发器里调用函数尝试改数据 → 触发器上下文同样禁止写操作，直接报错
- 误以为
SET @var := (SELECT ...)能触发副作用 → 变量赋值不等于执行，不会真正更新表
真正需要“计算并写入”的逻辑，就该交给存储过程、应用事务或正确设计的SQL语句。函数只负责回答“是什么”，不负责决定“变成什么”。这点边界模糊了，后续排查锁、一致性、主从延迟问题时会非常痛苦。
