将MySQL默认事务设为只读+读未提交，仅按需覆盖是否有利？

我的思路与策略 #

我考虑将以下策略应用于博客、内容发布这类读密集型系统（多数查询无需严格数据一致性）：

• 默认全局只读模式：把数据库默认设置为只读，既能捕获编程误写的错误，还可能提升读取性能

  -- MySQL / MariaDB 示例
  -- 读密集型系统中，默认只读以提升安全性和速度
  SET GLOBAL TRANSACTION READ ONLY;
  

• 默认最低事务隔离级别：全局设置最宽松的READ UNCOMMITTED隔离级别，避免锁定，提升读取性能

  -- MySQL / MariaDB 示例
  -- 若多数查询不要求数据完整性，选择性能优先的隔离级别
  SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
  

• 按需覆盖权限与隔离级别：仅针对需要写入或更高一致性的查询，临时修改会话级别的事务权限和隔离级别，读密集场景下这些额外操作的开销可以忽略

  -- MySQL / MariaDB 示例
  ...
  SET SESSION TRANSACTION READ WRITE;
  UPDATE table_x SET field_y=10;
  SET SESSION TRANSACTION READ ONLY;
  ...
  

存在的问题与为何未常规应用 #

1. 全局设置的运维阻碍 #

全局设置READ ONLY会限制所有新会话的操作，包括数据库备份、索引重建、数据迁移这类运维操作，如果没有提前针对性处理，这些必要操作会直接失败，大幅提升运维复杂度。

2. 宽松隔离级别的隐性风险 #

READ UNCOMMITTED虽然性能最高，但会引发脏读：读取到其他事务未提交的修改。哪怕是博客系统，比如编辑正在修改文章时，读者可能看到半编辑状态的内容，影响体验；如果有阅读量统计这类场景，脏读还会导致数据统计误差，对部分业务依然不可接受。

3. 会话级修改的代码隐患 #

每次写入前后手动切换事务模式，增加了代码冗余，一旦遗漏还原步骤，该会话后续所有操作都会保持读写模式，违背了“默认只读”的安全初衷；如果写入操作抛出异常，还原语句可能无法执行，直接引发后续误写风险。

4. 更成熟的替代方案 #

多数读密集系统会采用读写分离架构：主库负责写入，从库负责读取，从库可单独设置只读模式，还能针对不同业务配置合适的隔离级别，比全局修改更灵活可控；再加上Redis这类缓存层的广泛应用，已经能大幅降低数据库读取压力，无需依赖极端隔离级别来提升性能。

内容的提问来源于stack exchange，提问作者Patrick Savalle