存储过程无法动态决定是否开启事务，显式事务必须由BEGIN/START TRANSACTION明确启动；事务边界取决于调用上下文而非过程内部逻辑，DDL、GO、MyISAM表或跨过程SAVEPOINT均会导致隐式提交或断裂。
存储过程里不能“动态决定”是否开启事务
显式事务必须由 BEGIN TRANSACTION（SQL Server）或 START TRANSACTION（MySQL）明确启动，它不是开关变量，也不能靠 IF @flag = 1 BEGIN ... END 包裹后“条件性生效”。一旦没执行到那行 BEGIN，整个块就运行在 autocommit 模式下——每条 DML 独立提交，ROLLBACK 必然失败。
真正可控的是“事务边界是否由当前过程主导”
关键不在“要不要开”，而在“谁来开、什么时候开、开在哪一层”。常见错误是把 BEGIN TRANSACTION 塞进存储过程内部，却忽略调用链上下文：
- 如果调用方已执行
BEGIN TRANSACTION，你的过程内再写一次，只会让@@TRANCOUNT加 1；COMMIT也只减 1，事务实际未结束 - 如果调用方没开事务，而你过程里写了
START TRANSACTION（MySQL）或BEGIN TRAN（SQL Server），那它就是事务起点——但必须配对COMMIT/ROLLBACK，且不能被 DDL 中断 - SQL Server 中
SET XACT_ABORT ON应始终启用，否则某条语句报错（如主键冲突），后续语句仍会执行，ROLLBACK只能回滚出错那条，不是整个块
MySQL 存储过程中模拟“按需事务”的安全写法
MySQL 不支持在过程内判断是否已有事务，但可通过 SELECT @@autocommit 和 SELECT @@in_transaction 推断上下文。稳妥做法是：由调用方统一控制，过程只做“事务中执行”假设：
DELIMITER $$
CREATE PROCEDURE sp_transfer(
IN p_from VARCHAR(10),
IN p_to VARCHAR(10),
IN p_amount DECIMAL(10,2)
)
BEGIN
DECLARE exit handler for sqlexception
BEGIN
ROLLBACK;
RESIGNAL;
END;
<p>-- 不检查是否已有事务，而是信任调用方已 START TRANSACTION
UPDATE accounts SET balance = balance - p_amount WHERE id = p_from;
UPDATE accounts SET balance = balance + p_amount WHERE id = p_to;
END$$
DELIMITER ;
调用时必须显式包住：
START TRANSACTION;
CALL sp_transfer('A', 'B', 100.00);
-- 这里可加业务校验，比如查余额是否异常
COMMIT;
最容易被忽略的事务“隐形断裂点”
即使代码看着有 BEGIN 和 COMMIT，以下操作也会让事务提前终止，导致后续 ROLLBACK 失效：
- 任何 DDL 语句（
CREATE TABLE、ALTER PROCEDURE、DROP INDEX）——SQL Server 和 MySQL 均会隐式提交当前事务 - 在事务中执行
GO（仅 SSMS/SQLCMD）——它不是 T-SQL，会切断批处理上下文 - 跨存储过程调用时用了
SAVEPOINT，但目标过程内部又开了新事务，保存点作用域不继承 - MySQL 中混用 MyISAM 表——哪怕其他表都是 InnoDB，只要涉及 MyISAM，整段事务失去原子性
事务不是写完 BEGIN 就自动生效，它依赖整个执行路径上没有隐式提交、没有上下文切换、没有引擎不兼容。检查 @@TRANCOUNT（SQL Server）或 @@in_transaction（MySQL）是上线前必做的验证动作。
