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 做错误捕获。
