MySQL无法设置READ COMMITTED的真实原因是binlog_format=STATEMENT时自动降级为REPEATABLE READ，或存储引擎不支持（如MyISAM），而非权限或语法问题。
MySQL 无法 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 的真实原因
不是权限或语法问题，而是当前会话/全局隔离级别被显式禁用，或者存储引擎不支持。InnoDB 支持 READ COMMITTED，但 MyISAM 完全忽略事务隔离级别——执行后看似成功，实际不生效。更隐蔽的是：当 binlog_format = STATEMENT 且启用了二进制日志时，MySQL 会**自动降级** READ COMMITTED 为 REPEATABLE READ（仅限某些旧版本，如 5.6/5.7 默认行为），且不报错、不警告。
检查 binlog_format 是否触发了隐式降级
运行 SELECT @@binlog_format; 和 SELECT @@transaction_isolation; 对比预期与实际值。若你执行了 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; 后，再查 @@transaction_isolation 仍返回 REPEATABLE-READ，大概率是 binlog_format = STATEMENT 在起作用。
-
STATEMENT格式下，MySQL 为保证主从一致性，禁止在 RC 级别执行可能产生非确定性结果的语句（如带子查询的 UPDATE），因此直接锁定会话级别为 RR -
ROW或MIXED下，RC 可正常启用，因为行级事件天然支持更细粒度的并发控制 - 修改需重启或动态设置：
SET GLOBAL binlog_format = 'ROW';（注意：需 SUPER 权限，且已有连接不受影响）
确认当前连接是否真的运行在 READ COMMITTED
不能只信 SELECT @@transaction_isolation，它显示的是“期望级别”，而非“运行时生效级别”。正确验证方式是：
- 开启一个新会话，执行
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; - 启动事务：
BEGIN; - 查询
SELECT TRX_ISOLATION FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();—— 这里返回的才是 InnoDB 引擎当前事务的真实隔离级别 - 若返回
READ-COMMITTED，说明生效；若为空或返回REPEATABLE-READ，说明被覆盖或未真正进入事务上下文
为什么有些客户端工具里 SET 不生效？
常见于 JDBC、Python MySQLdb/PyMySQL、甚至 mysql 命令行客户端的自动提交模式干扰。例如：
- JDBC URL 中含
&useSSL=false&serverTimezone=UTC却漏掉&sessionVariables=transaction_isolation='READ-COMMITTED'，导致连接初始化后立即被服务端重置 - mysql 命令行默认 autocommit=1，
SET TRANSACTION必须在BEGIN之前、且不能跨语句保留（仅对下一个事务有效） - 某些 ORM（如 Django 2.x+）默认强制使用
REPEATABLE READ，即使数据库配置为 RC，也会在每次事务开始时覆盖
最稳妥的做法：不在应用层依赖会话级 SET，而是在创建连接时通过 init-command 或连接参数固化隔离级别，并确保 binlog_format 与之兼容。RC 的核心价值在于减少锁竞争，但如果 binlog 格式卡住它，那锁没少，一致性还可能出问题。
