MySQL函数体内禁止COMMIT/ROLLBACK是硬性语法限制，解析器在定义阶段即拒绝事务控制语句，因其定位为纯计算单元，须保证确定性与查询上下文安全；替代方案是使用支持事务的存储过程。
MySQL函数体内禁止COMMIT/ROLLBACK是硬性语法限制
不是权限问题，也不是配置没开，而是MySQL解析器在函数定义阶段就直接拒绝包含COMMIT、ROLLBACK、BEGIN WORK等事务控制语句。只要函数体里出现这些关键词，CREATE FUNCTION就会报ERROR 1305（FUNCTION does not exist）或ERROR 1422（Explicit or implicit commit is not allowed in stored function or trigger）。
函数设计定位决定它不能参与事务边界控制
MySQL把函数视为“纯计算单元”，必须满足确定性（DETERMINISTIC）或至少可预测的副作用（READS SQL DATA），而事务提交会改变全局状态、影响binlog顺序、破坏查询缓存一致性——这与函数被允许嵌入SELECT、WHERE甚至ORDER BY中的使用场景根本冲突。
- 你在
SELECT id, calc_status(id) FROM orders里调用函数，MySQL无法预判这个函数是否偷偷提交了事务，会导致整个查询语义失控 - 函数若允许
COMMIT，那它可能在一条UPDATE语句中途把前面已修改的行刷到磁盘，破坏原子性 - 复制环境下，函数内
COMMIT会打乱主从binlog事件顺序，造成数据不一致
替代方案：用存储过程封装事务逻辑
需要事务控制？必须换用CREATE PROCEDURE。它支持START TRANSACTION、COMMIT、ROLLBACK，也支持DECLARE HANDLER做异常捕获，还能用OUT参数返回结果——虽然调用方式变成CALL proc_name(?, @out)，但这是唯一合规路径。
- 别试图在函数里调用存储过程来绕过限制：函数中调用含事务的存储过程，仍会触发ERROR 1422
- 如果只是想“查完就提交”，说明你其实不需要函数——直接在应用层用预编译语句+事务块更安全、更可控
- 函数里能做的仅限于：查表（
SELECT ... INTO）、计算、字符串处理、类型转换，且所有SQL必须至多返回一行
容易忽略的隐式提交陷阱
除了显式的COMMIT，以下操作在函数体内也会触发隐式提交，同样被禁止：
-
CREATE TABLE、DROP TABLE等DDL语句（哪怕加了IF NOT EXISTS） -
ALTER TABLE、TRUNCATE TABLE -
LOCK TABLES、UNLOCK TABLES - 任何修改系统变量的
SET语句（如SET autocommit = 0）
这些限制不是为了刁难，而是防止函数在被优化器内联、并行执行或物化视图展开时，引发不可预测的状态污染——这点在高并发批量更新场景下尤其致命。
