mysql中查会话隔离级别优先用select @@transaction_isolation（8.0+），5.7及以下需用@@tx_isolation；全局级别须加@@global.前缀；真实运行时值需结合innodb_trx和performance_schema.variables_by_thread交叉验证。
查当前会话隔离级别：先试 @@transaction_isolation，报错就换 @@tx_isolation
MySQL 8.0+ 默认用 SELECT @@transaction_isolation，返回值类似 'REPEATABLE-READ'（带单引号、全大写、短横线）。在 5.7 或更早版本执行这条会直接报 Unknown system variable 'transaction_isolation'。这时候必须切到兼容写法：SELECT @@tx_isolation。别指望自动适配——变量名不匹配就是硬报错，没有 fallback 逻辑。
这个值只反映连接初始化时继承或显式 SET SESSION 设定的值，不是事务运行时的真实快照。比如事务中执行了 SET TRANSACTION ISOLATION LEVEL READ COMMITTED，再查 @@transaction_isolation 还是原来那个值。
-
@@session.transaction_isolation和@@transaction_isolation等价，可互换 - 权限受限账号下，
SELECT @@...可能因无SELECT权限失败，而SHOW VARIABLES LIKE 'transaction_isolation'只需USAGE权限，更稳妥 - 返回值带单引号（如
'READ-COMMITTED'），脚本解析时注意字符串清洗，别直接当裸字符串比较
查全局默认隔离级别：必须加 @@global. 前缀
想确认新建立的连接默认用什么级别，得明确查全局变量：SELECT @@global.transaction_isolation（8.0+）或 SELECT @@global.tx_isolation（5.7-）。漏掉 @@global. 就还是查会话级，容易误判成“全局已生效”。
这个值只决定后续新建连接的初始设置，不影响已有连接。它和配置文件里写的 transaction-isolation = READ-COMMITTED 是一回事——但改了配置必须重启 MySQL 才生效；SET GLOBAL TRANSACTION ISOLATION LEVEL ... 在 8.0+ 已被移除，执行会报错。
- 配置文件中变量名写成下划线（
transaction_isolation）或大小写混用（Transaction-Isolation），MySQL 启动时会静默忽略，日志里可能只有unknown variable提示 -
SHOW GLOBAL VARIABLES LIKE 'transaction_isolation'返回两列（Variable_name和Value），适合人工扫视；但字段顺序可能随版本微调，监控脚本建议坚持用SELECT @@global...
看当前活跃事务：查 INNODB_TRX 表最直接
隔离级别只是上下文，真正要定位“正在跑什么事务”，得看 information_schema.INNODB_TRX：SELECT * FROM information_schema.INNODB_TRX\G。它给出每个活跃事务的 trx_id、trx_state（如 RUNNING 或 LOCK WAIT）、trx_started 时间戳、对应线程 ID（trx_mysql_thread_id）以及正在执行的 SQL（trx_query）。
这个视图是排查长事务、锁等待、事务卡死的第一手依据。注意它只包含 InnoDB 引擎的事务，MyISAM 不在此列。
- 搭配
SHOW FULL PROCESSLIST，用trx_mysql_thread_id关联线程状态，能快速判断是“真执行中”还是“空闲 Sleep” -
trx_state = 'LOCK WAIT'说明该事务在等锁，下一步该查INNODB_LOCK_WAITS和INNODB_LOCKS - ORM（如 Django/SQLAlchemy）或连接池（如 HikariCP）常在建连后立即发 SET 语句覆盖隔离级别，光看
INNODB_TRX的trx_started时间，未必能反映业务代码实际开启事务的时机
查其他连接的隔离级别：用 performance_schema.variables_by_thread
如果要审计多个连接各自的隔离级别（比如排查某条慢查询是否因隔离级别设错导致），不能只查自己的会话。MySQL 5.7+ 提供了 performance_schema.variables_by_thread 表，可关联线程 ID 查每个连接的实际设置：
SELECT p.ID AS process_id, p.USER, p.DB, v.VARIABLE_VALUE AS isolation_level FROM information_schema.PROCESSLIST p JOIN performance_schema.variables_by_thread v ON v.THREAD_ID = p.THREAD_ID WHERE v.VARIABLE_NAME = 'transaction_isolation' AND p.COMMAND != 'Sleep';
这个查询能暴露 ORM 自动设的值、连接池预热时覆盖的值，甚至某些中间件悄悄下发的 SET 指令。但注意：performance_schema 默认可能未启用，需确认 performance_schema=ON 且相关 consumers 已打开。
- 该表只在事务处于活跃态（非 Sleep）时才稳定可见变量值；空闲连接可能查不到或返回 NULL
- 权限要求比
INNODB_TRX高，需要SELECT权限 +PERFORMANCE_SCHEMA访问权 - 返回的
VARIABLE_VALUE是字符串，格式与SELECT @@...一致，但注意它反映的是线程启动后最后一次 SET 的结果，不是连接池复用前的原始值
真实环境里，SELECT @@transaction_isolation 看到的往往只是“连接初始化快照”，而 ORM、连接池、中间件层层叠加的 SET 操作，可能早已在你执行第一条业务 SQL 前就改掉了它——别只信这个值，得结合 INNODB_TRX 和线程级变量交叉验证。
