MySQL函数内禁止执行START TRANSACTION、COMMIT或ROLLBACK，因其设计为无副作用的计算单元；DML操作可执行但须声明权限，且自动纳入外部事务；需事务控制应使用存储过程。
MySQL 函数内不能执行事务控制语句
MySQL 的存储函数（CREATE FUNCTION）在执行过程中**不允许显式使用 START TRANSACTION、COMMIT 或 ROLLBACK**。一旦函数体内出现这类语句，会直接报错：ERROR 1422: Explicit or implicit commit is not allowed in a stored function or trigger。
这是因为函数被设计为“无副作用”的计算单元，需保证调用时不会改变数据库状态（如修改数据、提交事务），否则在 SELECT 查询中调用函数可能导致不可预测的行为（比如部分行触发了提交，其他行未触发）。
- 即使函数内部只读，也不能加
COMMIT—— MySQL 不区分“是否真改了数据”，只要语法上出现就拒绝 -
INSERT/UPDATE/DELETE本身隐式触发事务行为，但函数里允许执行这些语句（前提是函数定义时声明了READS SQL DATA或更低限制） - 函数可调用其他函数或存储过程，但如果被调用者含事务控制，同样会在运行时报错
函数调用受外部事务控制
函数本身不开启/结束事务，但它所执行的 DML 操作（如 UPDATE）会**自动纳入当前会话的活跃事务中**。也就是说，函数不是事务的边界，而是嵌入在外部事务里的一个执行片段。
例如：你在事务块中调用一个更新数据的函数，该函数内部的 UPDATE 不会单独提交；整个事务最终由你决定是 COMMIT 还是 ROLLBACK。
- 若函数执行失败（比如违反约束），抛出异常会导致整个外部事务回滚（取决于错误处理逻辑和 autocommit 设置）
- 函数中发生死锁、超时等错误，也会中断当前事务流程
- 函数返回值不影响事务状态，但它的副作用（如修改表）会影响后续语句可见性
想封装事务逻辑？改用存储过程
如果需要在一段逻辑中控制事务（比如先插入再更新，失败则整体回滚），必须使用 CREATE PROCEDURE，而不是函数。过程支持完整的事务语句，并能配合 DECLARE HANDLER 做错误捕获。
典型结构如下：
CREATE PROCEDURE do_something()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
ROLLBACK;
START TRANSACTION;
INSERT INTO t1 VALUES (1);
UPDATE t2 SET x = 2 WHERE id = 1;
COMMIT;
END
- 函数无法替代过程来实现事务封装，二者定位不同：函数用于计算并返回值，过程用于执行操作
- 过程可以调用函数，但函数不能调用过程（会报
ERROR 1424） - 从安全角度，MySQL 对函数的权限限制更严（如
log_bin_trust_function_creators参数影响主从复制）
函数中访问临时表或用户变量的风险
虽然函数允许读写临时表、使用用户变量（@var），但这些操作仍处于外部事务上下文中，且可能引发一致性问题。
- 临时表在事务中创建后，其生命周期绑定到会话，不是事务级，所以
ROLLBACK不会删它 - 用户变量跨语句保留，但在函数多次调用间可能残留旧值，尤其在连接复用（如连接池）场景下容易出错
- 函数内使用
SELECT ... INTO赋值给局部变量是安全的，但避免依赖会话级状态
真正容易被忽略的是：函数看似“只读”，但只要它包含任何 DML，就可能在不经意间破坏事务隔离性——比如在 REPEATABLE READ 隔离级别下，函数内 SELECT 看到的是事务快照，而其中的 UPDATE 却会更新最新版本，造成幻读类现象。
