MySQL存储过程中SET TRANSACTION ISOLATION LEVEL无效，因其仅影响后续新事务，不改变当前已开启事务的隔离级别；防幻读需在REPEATABLE READ下用SELECT ... FOR UPDATE加锁覆盖间隙，而非切换隔离级别。
MySQL 存储过程中无法直接用 SET TRANSACTION ISOLATION LEVEL 动态切换隔离级别来规避脏读或幻读——该语句只对后续新开启的事务生效，而存储过程内执行的语句默认复用当前会话已开启的事务上下文。
为什么在存储过程里 SET TRANSACTION 不起作用
当你在已启动事务（如显式 START TRANSACTION 或隐式自动提交关闭）的会话中调用存储过程，过程内部的 SQL 语句就运行在这个事务里。此时执行 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 只影响“下一个事务”，不改变当前正在执行的事务的隔离行为。
- MySQL 的隔离级别是事务级的，不是语句级或过程级的
- 存储过程本身不是事务边界，它只是代码容器；事务边界由
START TRANSACTION/BEGIN和COMMIT/ROLLBACK定义 - 若你在存储过程开头写
SET TRANSACTION ISOLATION LEVEL ...，它只对接下来START TRANSACTION开启的那个事务有效，而非过程内所有语句
真正能控制脏读的实用做法：用 SELECT FOR UPDATE + REPEATABLE READ
MySQL 默认隔离级别是 REPEATABLE READ，它天然避免脏读和不可重复读，但幻读需配合加锁才能堵住。关键不是改隔离级别，而是让查询带锁：
- 对要校验或更新的关键行，用
SELECT ... FOR UPDATE（当前读），触发行锁 + 间隙锁（Gap Lock），阻止其他事务插入/修改 - 避免只用普通
SELECT（快照读），它不加锁，即使在REPEATABLE READ下也看不到新插入的行，但无法阻止别人插入 → 幻读风险仍在 - 示例场景：库存扣减前查余额，必须用
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;，而不是SELECT balance FROM accounts WHERE id = 1;
幻读必须靠锁范围覆盖，不能只靠 SERIALIZABLE
虽然 SERIALIZABLE 理论上能杜绝幻读，但在 MySQL 中它会把普通 SELECT 自动转成 SELECT LOCK IN SHARE MODE，带来严重锁竞争和死锁风险，实际项目基本不用。
- 更可控的方式是：保持
REPEATABLE READ，在业务关键路径上主动使用SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE - 确保 WHERE 条件能命中索引，否则间隙锁可能升级为表锁，拖垮并发
- 如果查询条件是范围（如
WHERE created_at > '2025-01-01'），InnoDB 会锁住满足条件的索引间隙，防止插入新记录 —— 这才是防幻读的真实机制
真正容易被忽略的点是：**幻读不是“读到了不该读的数据”，而是“两次相同查询返回了不同数量的行”，它的根源在于锁没覆盖到插入点。所以重点从来不是换隔离级别，而是让 SELECT 带锁、且锁得住范围。**
