会话级隔离级别必须在事务开始前设置，若当前连接已处于活跃事务中，MySQL会报错“Can't change transaction isolation level when a transaction is active”；正确做法是先确认事务状态（SELECT @@in_transaction）、提交或回滚后再设置，或在连接建立初期即配置。
会话级隔离级别必须在事务开始前设置
执行 SET SESSION TRANSACTION ISOLATION LEVEL 时，如果当前连接已处于活跃事务中（比如已执行 START TRANSACTION 或 BEGIN，或 AUTOCOMMIT = 0 下执行了第一条 DML），MySQL 会直接报错：Can't change transaction isolation level when a transaction is active。这不是语法错误，而是 InnoDB 的硬性限制。
实操建议：
- 先确认当前事务状态：
SELECT @@in_transaction;返回1表示有活跃事务，需先COMMIT或ROLLBACK - 更稳妥的做法是：连接一建立就立刻设置，不要等业务逻辑跑起来再改
- 若用连接池（如 HikariCP、Druid），需确保初始化 SQL 中包含该语句，且放在
connectionInitSql而非普通查询里
支持的语法格式和常见拼写陷阱
MySQL 接受多种写法，但不兼容的写法会导致静默失败或报错。关键不是大小写，而是关键字顺序和分隔符。
正确写法（任选其一）：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;-
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;（SESSION可省略） -
SET SESSION TRANSACTION ISOLATION LEVEL 'READ-COMMITTED';（带单引号也合法）
错误写法：
-
SET SESSION tx_isolation = 'READ-COMMITTED';（tx_isolation是旧变量名，MySQL 8.0+ 已弃用，可能报错或不生效） -
SET SESSION TRANSACTION ISOLATION LEVEL READ_COMMITTED;（下划线_替代短横线-，MySQL 会识别为非法值） -
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED（结尾缺分号，在某些客户端如 MySQL Shell 中会卡住等待输入）
验证是否生效不能只看 SELECT @@transaction_isolation
SELECT @@transaction_isolation; 确实返回当前会话值，但它只反映“最近一次 SET 的结果”，不保证后续操作真按这个级别执行——尤其当连接被复用、或事务自动开启时容易误判。
更可靠的验证方式：
- 在设置后立即开一个新事务：
BEGIN; SELECT @@transaction_isolation; COMMIT;，排除 autocommit=1 下的快照干扰 - 用可复现的并发行为验证：比如开两个会话，A 在
READ COMMITTED下查某行，B 修改并提交，A 再查是否看到新值 - 注意：某些 ORM（如 MyBatis、JPA）会在每次执行前重置隔离级别，此时手动 SET 可能被覆盖，得查框架文档确认是否支持连接级透传
会话级设置对连接池和长连接的影响
连接池里的连接是复用的，上一个请求设置的 READ COMMITTED，下一个请求如果不显式重设，依然沿用该级别——这既是便利也是隐患。
典型风险场景：
- 微服务中，订单服务设为
REPEATABLE READ，用户中心服务设为READ COMMITTED，但共用同一个连接池，未做连接隔离，导致事务行为不一致 - HTTP 请求结束后未显式
COMMIT或ROLLBACK，连接归还池中时仍处于事务中，下次取出时隔离级别虽保留，但事务状态异常 - PHP 的
mysqlnd扩展在mysqli::close()时不会清理会话变量，复用连接时旧设置残留
真正安全的做法：每个业务逻辑入口处，明确声明所需隔离级别，而不是依赖连接初始状态。复杂业务里，别指望“设一次管全程”。
