MySQL 8.0+ 应使用 SELECT @@transaction_isolation 查当前会话隔离级别，5.7 及以前用 SELECT @@tx_isolation；混用会报“Unknown system variable”错误，且该值仅反映会话初始化设置，不体现事务内临时变更或 ORM 覆盖行为。
直接执行 SELECT @@transaction_isolation; 就能拿到当前会话的隔离级别，但必须根据 MySQL 版本选对变量名，否则报错或返回空。
查当前会话用哪个变量名
MySQL 8.0+ 必须用 @@transaction_isolation，5.7 及更早版本只认 @@tx_isolation。混用会触发 Unknown system variable 错误。
- 先试
SELECT @@transaction_isolation;，如果报错就立刻换SELECT @@tx_isolation; - 返回值是字符串，如
REPEATABLE-READ（8.0+）或'REPEATABLE-READ'（5.7，带单引号）——注意格式差异会影响脚本解析 - 这个值只反映当前连接的设置，和 ORM、连接池初始化时覆盖的行为无关，不能代替实际业务行为验证
查全局默认值必须加 @@global. 前缀
想确认新连接默认用什么级别，得显式查全局变量，漏掉 global 还是查会话级，容易误判。
- 执行
SELECT @@global.transaction_isolation;（8.0+）或SELECT @@global.tx_isolation;（5.7） - 该值不受当前会话影响，只决定后续新建连接的初始值
- 配置文件里写了
transaction-isolation = READ-COMMITTED但没生效？检查 MySQL 是否真读了那个my.cnf，比如启动时指定了--defaults-file
SHOW VARIABLES 也能查，但要注意作用域
SHOW VARIABLES LIKE 'transaction_isolation'; 查的是会话级，SHOW GLOBAL VARIABLES LIKE 'transaction_isolation'; 才是全局级——别漏掉 GLOBAL 关键字。
- 这条命令返回两列：
Variable_name和Value，比SELECT @@...多一列，适合人工快速扫视 - 在权限受限账号下，
SELECT @@...可能因无 SELECT 权限报错，而SHOW VARIABLES只需 USAGE 权限，更稳妥 - 不推荐用
SHOW VARIABLES写监控脚本，因为字段顺序和列名可能随版本微调，SELECT @@...更稳定
事务中改了隔离级别，SELECT @@transaction_isolation 看不到
事务内执行 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; 后，SELECT @@transaction_isolation 仍返回会话默认值——它不反映运行时临时变更。
- 这个变量是只读快照，只表示会话启动时继承或显式
SET SESSION设定的值 - 真正生效的是事务启动那一刻确定的级别，靠
SET TRANSACTION ISOLATION LEVEL设置，且必须在BEGIN后、首条 DML 前执行 - ORM（如 Django、SQLAlchemy）常在连接建立时自动设隔离级别，手动
SET可能被后续框架 SQL 覆盖，得看日志确认实际执行顺序
最易忽略的是：连接池复用连接时，会话级设置不会跨请求保留；而事务级设置又无法被 SELECT @@... 观测到。真要验证行为，得结合具体 SQL 执行结果，而不是只信这个变量值。
