MySQL默认隔离级别仍是REPEATABLE READ，根本原因不是安全性更高，而是兼容ORM和中间件对事务级ReadView及间隙锁的隐式依赖，即便ROW格式binlog已使RC主从一致。
MySQL 8.0 默认仍是 REPEATABLE READ，不是因为“更安全”或“更适合业务”，而是为了向后兼容旧复制逻辑和中间件行为——哪怕你已经用 binlog_format=ROW。
为什么 RC 在 ROW binlog 下已安全，但默认没改
MySQL 5.7 起就默认启用 binlog_format=ROW，它记录的是行变更前后的镜像，不再依赖 SQL 执行顺序，READ COMMITTED 不再有主从错位风险。但默认隔离级别仍锁死在 REPEATABLE READ，原因很实际：
- 大量 ORM（如 Hibernate、MyBatis）和分库中间件（如
ShardingSphere、MyCat）隐式依赖 RR 的事务级ReadView行为：事务启动时建一次快照，后续所有SELECT都复用 —— 这被当成“事务内一致性”的事实标准 - 有些业务代码靠两次快照读比对结果（比如“查余额→扣款→再查余额”做幂等校验），换成 RC 后第二次
SELECT可能读到新提交数据，逻辑直接崩 - RR 的间隙锁虽带来并发压力，但对某些强一致场景（如唯一约束校验、防重复插入）提供了“当前读层面”的确定性拦截能力，RC 连这个兜底都没有
RR 的“安全性”只在 STATEMENT binlog 下是刚需
这是最容易被忽略的点：RR 强制加 Next-Key Lock 的根本动机，是堵住早期 STATEMENT 格式 binlog 下的主从执行顺序漏洞。一旦切到 ROW，这个锁机制就从“必要防护”退化为“额外开销”：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
REPEATABLE READ下，一个长事务会阻止purge线程清理 undo 日志，版本链持续膨胀，拖慢全表扫描和历史版本构造 - 间隙锁持有时间更长，范围更新（如
UPDATE t SET x=1 WHERE id > 100）容易阻塞无关插入，死锁概率比 RC 高数倍 - 很多监控工具、审计插件默认按 RR 语义解析事务行为，硬切 RC 可能导致指标误报或告警失灵
生产环境真要切 RC，必须验证这三件事
大厂线上普遍用 READ COMMITTED，但切换不是改个配置就行，得确认：
- 所有涉及“两次查询 + 中间写入”的业务逻辑是否显式加了
SELECT ... FOR UPDATE或重试机制？否则不可重复读会暴露 - 是否禁用了
innodb_locks_unsafe_for_binlog（已废弃）或类似兼容开关？某些老版本驱动在 RC 下可能绕过行锁 - 备份恢复链路（如
mysqldump --single-transaction）是否仍能保证一致性？该命令依赖 RR 的事务快照能力，切 RC 后需改用--lock-all-tables或其他方案
真正难的不是知道该选 RR 还是 RC，而是搞清你的业务到底在哪个环节悄悄依赖了 RR 的快照时机或锁行为——这些地方往往没注释、没文档、测试覆盖不到。
