MySQL存储过程执行时继承当前会话的隔离级别，其SELECT查询、加锁行为及一致性视图均取决于会话设置；显式START TRANSACTION可覆盖该设置，否则全程遵循会话级transaction_isolation。
存储过程执行时会继承当前会话的隔离级别
MySQL 存储过程本身不定义或更改事务隔离级别，它完全依赖调用它的会话（session）所设置的 tx_isolation 或 transaction_isolation 值。这意味着：同一段存储过程代码，在 REPEATABLE READ 下执行和在 READ COMMITTED 下执行，其 SELECT 查询看到的数据快照、加锁行为、甚至是否阻塞，都可能完全不同。
常见错误现象是：开发时在测试环境（默认 REPEATABLE READ）调试通过，上线后在某些连接池配置下被设为 READ COMMITTED，结果出现“数据读取不一致”或“幻读导致重复处理”。这不是存储过程写错了，而是隔离级别变了，MVCC 快照生成逻辑跟着变了。
-
REPEATABLE READ：事务启动时创建一个全局一致性视图（readview），整个事务内所有 SELECT 都复用这个视图 -
READ COMMITTED：每次 SELECT 执行前都新建一个 readview，因此两次查询之间若其他事务提交了新数据，第二次就能看到 -
SELECT ... FOR UPDATE或UPDATE等当前读操作，在不同级别下加锁范围也不同（比如REPEATABLE READ会用 Next-Key Lock 防幻读，READ COMMITTED只加记录锁）
存储过程中显式开启事务时，隔离级别由 START TRANSACTION 语句决定
如果存储过程内部用了 START TRANSACTION 或 BEGIN，那么该事务的隔离级别取决于是否在语句中显式指定。例如：
START TRANSACTION ISOLATION LEVEL READ COMMITTED;
这种写法会覆盖会话级设置，强制本次事务使用 READ COMMITTED。但注意：START TRANSACTION 不带参数时，**仍继承会话级别**，不是默认 REPEATABLE READ —— 这点容易误解。
使用场景：某个存储过程需要强一致性读（如对账），但所在应用连接池统一设为 READ COMMITTED，这时就必须在过程开头用带参数的 START TRANSACTION 显式升到 REPEATABLE READ。
- MySQL 8.0+ 支持
START TRANSACTION ... ISOLATION LEVEL语法；5.7 及更早版本需先SET SESSION transaction_isolation = 'REPEATABLE-READ' - 显式指定后，该事务内的所有读写都按新级别生效，与外部会话设置无关
- 未显式指定时，哪怕存储过程跨多个语句，也始终遵循调用者 session 的
transaction_isolation值
函数/过程内嵌查询受 MVCC 快照影响，但函数本身不可被事务回滚
存储过程里调用的函数（尤其是 DETERMINISTIC 或 READS SQL DATA 类型）在执行 SELECT 时，同样走当前事务的 MVCC 路径。但要注意：函数体内的语句不能开启或提交事务，也不能被外层事务回滚 —— 它只是“读”，不是“事务单元”。
典型陷阱是：写了一个函数 get_user_balance(user_id)，在 REPEATABLE READ 下返回缓存余额，但业务逻辑误以为它能反映最新扣款状态；实际上该函数返回的是事务开始那一刻的快照值，哪怕外面刚执行过 UPDATE 也没用。
- 函数内 SELECT 使用的 readview，取决于它被调用时所在的事务上下文，不是函数定义时的环境
- 函数不能包含
COMMIT/ROLLBACK，否则报错ERROR 1305 (42000): FUNCTION does not exist（实际是语法限制） - 若函数声明为
MODIFIES SQL DATA并含 INSERT/UPDATE，这些修改会被外层事务一并回滚 —— 但函数内 SELECT 读到的数据仍是快照，不会因后续回滚而改变
最易被忽略的点：AUTOCOMMIT=0 时，存储过程执行全程都在一个隐式事务里
当会话 autocommit = 0，且没有显式 START TRANSACTION，那么存储过程里的每条语句（包括 SELECT、UPDATE）都会被包裹进一个自动开启又自动提交的事务 —— 但这个行为只在 autocommit = 0 且语句非 DDL 时成立。关键在于：**这个隐式事务的隔离级别，仍然取自会话设置，且每次语句都是独立快照**。
也就是说，在 autocommit = 0 + READ COMMITTED 下，存储过程里连续两条 SELECT 可能读到不同结果；而在 autocommit = 0 + REPEATABLE READ 下，它们共享同一个快照 —— 这种差异往往在压测时才暴露。
- 不要假设“存储过程天然在一个事务里”：只有显式
BEGIN/START TRANSACTION才真正开启事务边界 -
autocommit = 0是危险配置，尤其对存储过程，容易让开发者误判一致性边界 - 检查实际生效级别，别只看
SELECT @@transaction_isolation，还要确认是否被连接池或 ORM 框架动态修改过
