最直接查看mysql事务隔离级别是执行select @@transaction_isolation;或旧版select @@tx_isolation;，返回值如'read-committed'等，需结合binlog格式、orm行为等综合判断实际效果。
查看当前 MySQL 事务隔离级别
最直接的方式是执行 SELECT @@transaction_isolation; 或 SELECT @@tx_isolation;（旧版本兼容）。注意：5.7.20+ 默认用 @@transaction_isolation，如果返回空或报错 Unknown system variable 'tx_isolation'，说明必须用新变量名。
常见返回值有：'READ-COMMITTED'、'REPEATABLE-READ'（MySQL 默认）、'READ-UNCOMMITTED'、'SERIALIZABLE'。别只看名字，得结合实际行为判断——比如即使设成 REPEATABLE-READ，在非唯一索引上做范围查询仍可能被幻读影响。
全局设置 transaction_isolation（重启不丢失）
改配置文件比运行时 SET 更可靠，尤其对连接池、后台任务等场景。编辑 my.cnf 或 my.ini，在 [mysqld] 下加一行：
transaction_isolation = READ-COMMITTED
然后重启 MySQL。不重启的话，该配置不会生效——很多人漏掉这步，改完配置却还看到旧值。
- 值必须全大写、用短横线（
READ-COMMITTED），不能写成read committed或ReadCommitted - 如果配置语法错误（比如多空格、拼错单词），MySQL 启动会失败，日志里报
unknown variable 'transaction_isolation'类似错误 - 该设置只影响后续新连接，已存在的连接仍保持原隔离级别
会话级临时修改 isolation level（适合调试）
用 SET TRANSACTION ISOLATION LEVEL 可以在当前连接里立刻切换，比如排查某个 SELECT 是否被幻读干扰：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
但要注意：这个命令必须在事务开启前执行；如果已经 BEGIN 或执行了第一条 DML，再 SET 就无效，MySQL 会静默忽略，也不报错。
- 会话级设置不会影响其他连接，关掉这个终端就失效
-
SET SESSION transaction_isolation = 'SERIALIZABLE';效果相同，但更显式 - 某些 ORM（如 Django）会在连接初始化时强制覆盖隔离级别，此时手动 SET 可能被框架重置
为什么 READ-COMMITTED 在 binlog=ROW 时更安全？
当 MySQL 开启 GTID 或需要主从一致时，REPEATABLE-READ 配合 STATEMENT 格式 binlog 容易出问题：同一个事务里两次 SELECT 可能因主从执行时间差导致结果不一致。而 READ-COMMITTED + ROW 是官方推荐组合。
检查方式：SHOW VARIABLES LIKE 'binlog_format'; 和 SHOW VARIABLES LIKE 'gtid_mode';。如果两者都启用，又没设 READ-COMMITTED，主从延迟或数据不一致的风险会明显升高。
-
READ-COMMITTED下，每个 SELECT 都能看到已提交的最新快照，避免长事务拖慢 MVCC 清理 - 但代价是：同一事务内多次读可能结果不同，应用层得接受这种“不一致性”
- 有些老业务依赖
REPEATABLE-READ的强一致性语义，切之前务必全链路压测
SELECT @@transaction_isolation; 看一眼。
