存储过程内BEGIN TRANSACTION失效，因SQL Server和MySQL默认自动提交，过程内事务在退出时隐式提交，导致后续ROLLBACK无目标；必须由调用方显式开启事务并控制全程。
存储过程里写 BEGIN TRANSACTION 或 START TRANSACTION 不能保证事务生效——事务边界必须由调用方显式控制，否则 ROLLBACK 会报错或静默失效。
为什么存储过程内 BEGIN TRANSACTION 失效？
SQL Server 和 MySQL 默认都启用自动提交（autocommit = 1），每条语句执行完立刻提交。你在存储过程里写 BEGIN TRANSACTION，只对当前过程内的语句起作用；过程一退出，事务就隐式提交了，后续的 ROLLBACK 没有可回滚的内容。
- SQL Server 报错：
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION - MySQL 中
DECLARE EXIT HANDLER捕获到异常后执行ROLLBACK，但因事务早已提交，实际无效果 - 过程里执行 DDL（如
ALTER TABLE）会触发隐式COMMIT，前面所有 DML 都无法回滚 - 跨表操作时混用 MyISAM 和 InnoDB 表，整个事务失去原子性
正确做法：事务由调用方开启，存储过程只做业务和异常响应
调用方负责事务起点和终点，存储过程专注逻辑与错误处理。这是唯一能确保 ROLLBACK 真正生效的方式。
- 调用前显式执行：
START TRANSACTION（MySQL）或BEGIN TRANSACTION（SQL Server） - 再执行存储过程：
CALL proc_transfer()或EXEC proc_update_batch - 根据返回值或输出参数决定：
COMMIT或ROLLBACK - 存储过程内部用
TRY...CATCH（SQL Server）或DECLARE EXIT HANDLER FOR SQLEXCEPTION（MySQL）捕获错误，但仅用于记录日志或设标志位，不主动ROLLBACK - 若需局部回滚（比如注册用户+发邮件失败不删用户），在调用方事务中提前设
SAVEPOINT sp_after_user_insert，失败时由调用方执行ROLLBACK TO sp_after_user_insert
批量更新场景下特别容易踩坑
一次更新上万行却塞进单个事务，不仅慢，还极易触发死锁（如 SQL Server 的 1205）或长时间锁表。
- 必须分批：建议每 500 行一批，用
WHILE循环 +OFFSET-FETCH（SQL Server）或LIMIT/OFFSET（MySQL）控制范围 - 必须按主键升序访问：加
ORDER BY id强制访问顺序一致，避免多会话交叉加锁引发死锁 - 传参别用逗号拼接字符串：易被注入，也难走索引；优先用表变量（SQL Server）或 JSON 参数（MySQL 5.7+）
- 避免在循环里反复
SELECT ... FOR UPDATE：锁持有时间过长，阻塞并发 - 检查影响行数：
IF @@ROWCOUNT = 0或ROW_COUNT() = 0，防止 WHERE 条件写错导致“假成功”
验证 ROLLBACK 是否真生效的两个硬指标
别信“没报错=成功”，得看数据状态和事务元信息。
- 执行
ROLLBACK后立刻查表确认变更消失；注意SELECT是否带FOR UPDATE，否则可能读到旧快照 - 查事务活跃状态：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID()（MySQL），结果为空才代表事务真正结束 - SQL Server 可查
SELECT @@TRANCOUNT：只有 > 0 时ROLLBACK才有意义；执行后应为 0 - 日志必须写在
CATCH或EXIT HANDLER内，但避免在其中执行可能失败的操作（如写日志表时磁盘满），否则会掩盖原始错误
真正麻烦的不是语法写不对，而是事务上下文根本没建立起来——调用方没开事务，存储过程再怎么写 ROLLBACK 都是空转。所有“局部回滚”“异常兜底”的前提，都是先有真实事务体存在。
