mysql存储过程本身不定义隔离级别，完全继承调用会话的transaction_isolation设置；若内部显式开启事务，则可通过start transaction isolation level（mysql 8.0+）或先set session transaction_isolation再begin来覆盖会话级配置；未显式指定时始终遵循会话设置，而非默认repeatable read。
MySQL存储过程本身不改变事务隔离级别，它只是“被动执行者”——实际并发表现完全由调用它的会话的transaction_isolation决定。想统计不同隔离级别下的行为差异，关键不是改存储过程代码，而是控制调用上下文并观测其内部查询的读取效果和锁行为。
怎么让同一个存储过程在不同隔离级别下运行？
存储过程不自带隔离级别设置，必须由外部会话或内部显式事务控制：
- 最常用方式：调用前用
SET SESSION TRANSACTION ISOLATION LEVEL切换会话级配置，例如SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 若过程内含
START TRANSACTION，且MySQL ≥ 8.0，可直接带参数：START TRANSACTION ISOLATION LEVEL REPEATABLE READ; - MySQL 5.7 或更早版本不支持
ISOLATION LEVEL参数，需先SET SESSION transaction_isolation = 'REPEATABLE-READ';再START TRANSACTION - 注意：
START TRANSACTION不带参数时，**仍继承当前会话设置**，不是默认REPEATABLE READ——这是高频误解点
如何验证存储过程里SELECT看到的数据快照是否符合预期？
核心是观察同一事务内多次SELECT是否返回一致结果，以及能否读到其他事务刚提交的新数据：
- 在
REPEATABLE READ下，过程内第一次SELECT生成readview，后续所有SELECT复用该视图；即使其他事务已提交新数据，也看不到 - 在
READ COMMITTED下，每次SELECT都新建readview，因此两次查询之间若被其他事务更新并提交，第二次就能读到新值 - 可在存储过程中插入
SLEEP(1)并手动在另一会话提交数据，然后检查后续SELECT结果变化——这是最直接的验证手段 - 避免依赖
SELECT @@transaction_isolation只查一次，应结合实际读取行为判断，因为变量值可能和真实MVCC行为脱节
为什么存储过程里的SELECT ... FOR UPDATE在不同级别下加锁范围不同？
加锁行为直接受隔离级别影响，这会显著改变并发阻塞表现：
-
REPEATABLE READ下，SELECT ... FOR UPDATE默认使用Next-Key Lock（记录锁 + 间隙锁），能阻止幻读，但也会锁住查询范围内的空隙，容易引发锁等待 -
READ COMMITTED下，同一条SELECT ... FOR UPDATE只加记录锁，不锁间隙，因此并发插入可能成功，但也导致幻读风险 - 若存储过程包含按条件更新+校验逻辑（如“余额充足才扣款”），在
READ COMMITTED下可能因间隙未被锁定，被其他事务插入符合条件的新行，造成业务逻辑错乱 - 用
SHOW ENGINE INNODB STATUS\G查看TRANSACTIONS和LOCK WAIT部分，能确认锁类型和等待关系，比单纯看SQL更可靠
真正难的是把隔离级别、MVCC快照、锁策略三者联动起来看——比如一个看似简单的SELECT COUNT(*) WHERE status=1，在REPEATABLE READ下可能长期持有间隙锁，在READ COMMITTED下虽不锁间隙，但多次执行可能拿到不同计数。这些细节不会报错，却会在高并发时突然暴露为超时或重复处理。
