结论：MySQL存储过程中禁止使用START TRANSACTION——事务必须由客户端连接层控制，存储过程仅专注业务逻辑，不可自行开启、提交或回滚事务。
MySQL存储过程里不能用START TRANSACTION
直接说结论：在MySQL存储过程中，START TRANSACTION语句是被禁止执行的——不是语法错误，而是运行时报错：ERROR 1305 (42000): SAVEPOINT does not exist或更常见的ERROR 1290 (HY000): The MySQL server is running with the --disable-gtid-strict-mode option（实际和GTID无关），本质是MySQL不允许在存储过程体内部显式发起新事务。
原因很简单：事务边界必须由客户端连接层控制。存储过程只是服务端的一段可复用逻辑，它跑在已有会话上下文中；如果允许它自己START TRANSACTION，就可能嵌套、覆盖或干扰调用方的事务控制流，破坏ACID一致性。
常见错误现象：
- 写完存储过程，里面写了
START TRANSACTION，调用时直接报错退出 - 误以为“加了
BEGIN...END就是事务”，结果DML没回滚 - 在存储过程中调用
COMMIT或ROLLBACK，发现只影响当前过程内语句，但外部事务已失控
事务控制必须放在调用端，不是存储过程里
正确的做法是：把事务逻辑交给调用者（比如应用代码或另一个SQL脚本），让存储过程只专注业务逻辑，不碰START TRANSACTION、COMMIT、ROLLBACK这些语句。
使用场景举例：你有一个transfer_money()存储过程，要做A账户扣款+B账户入账。它不该自己开启事务，而应假设调用方已开启，并在出错时抛异常让调用方决定回滚。
实操建议：
- 存储过程内部用
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获错误，然后RESIGNAL或SIGNAL自定义错误，不自行ROLLBACK - 调用时统一用
START TRANSACTION包裹多个存储过程调用，例如：START TRANSACTION; CALL transfer_money('A', 'B', 100); CALL log_transaction('A->B', 100); COMMIT; - 如果存储过程里有DDL（如
CREATE TEMPORARY TABLE），注意它会隐式提交当前事务，这是容易被忽略的坑
autocommit=0和存储过程的关系很脆弱
有人试过把会话设成SET autocommit = 0，再调用带DML的存储过程，以为这样就能自动成事务——不行。因为MySQL在进入存储过程时，会临时把autocommit强制置为1（除非显式用START TRANSACTION开启），过程结束又恢复原值。所以过程内的DML默认自动提交，不受外层autocommit控制。
参数差异与影响：
-
autocommit=1（默认）：每个DML单独提交，存储过程内每条INSERT都立刻落盘 -
autocommit=0+ 无START TRANSACTION：效果等同于autocommit=1，存储过程内仍自动提交 - 只有
START TRANSACTION显式开启后，后续所有语句（包括存储过程调用中的DML）才进入同一事务
性能提示：频繁调用小存储过程却不包事务，会导致大量小事务，刷盘压力大、并发吞吐下降。
想在过程里“模拟”事务？别硬来
有些场景看起来非得在过程里控制事务不可，比如动态拼接SQL、多分支写操作。这时候常见错误是用SAVEPOINT+ROLLBACK TO SAVEPOINT来回滚局部错误——但它不能替代事务，因为无法回滚跨语句的锁、无法防止其他会话提前读到中间状态。
真正可行的替代思路：
- 用临时表缓存中间结果，最后统一
INSERT INTO ... SELECT落地，失败就清空临时表 - 把分支逻辑拆成多个原子存储过程，由调用端按需组合并包事务
- 改用应用层事务（如Java的
@Transactional），让MySQL只做数据操作，不承担流程编排
最容易被忽略的一点：MySQL 8.0+ 支持GET DIAGNOSTICS获取错误上下文，但依然不能绕过“事务必须由客户端启动”这个底层约束。所有试图在过程里重开事务的努力，最后都会撞在隔离级别、锁行为或GTID一致性上。
