将MySQL默认事务模式设置为READ ONLY和READ UNCOMITTED，并且只在需要时重写，这会有好处吗

Question

以下策略似乎有效，但我是否忽略了什么？对于大多数查询不需要数据一致性的读密集型系统，为什么不总是这样做呢？比如博客/出版系统。在我看来

• 将数据库默认设置为只读模式。这将捕获编程错误，并可能提供更好的读取性能

  -- MySQL / MariaDB schema creation example
  -- in a read intensive system, default to read only for security and speed
  SET GLOBAL TRANSACTION READ ONLY;
  

• 将数据库默认设置为最不严格的事务隔离级别。这将防止锁定，并可能提高的读取性能

  -- MySQL / MariaDB schema creation example
  -- if data integrity is not critical for most queries, choose maximum performance
  SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
  

• 仅覆盖那些确实需要写访问权限和/或更高事务隔离级别的查询。在读密集型系统中，围绕写语句的这些额外的查询语句不会引起的注意

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

Answer 1

我从来没有听说过READ UNCOMITTED是正确的做法。很明显，从其他尚未提交并可能回滚的事务中读取更改可能会导致大量虚幻读取和其他逻辑问题。

我赞成将默认事务隔离级别设置为READ COMMITTED，尽管这也取决于应用程序的需要。某些应用程序要求默认情况下使用REPEATABLE READ语义。我们不能说其中的一个或另一个是"；"更好"；因为这取决于应用程序需要什么。

我不知道将事务访问模式设置为只读有任何性能优势。它可以防止该事务更改任何数据，但在我看来，如果你有代码错误，以至于你不知道给定的事务是否会更改数据，那么你就会遇到更大的问题。

InnoDB有一个只读模式，它影响整个实例，而不是单个事务。点击此处阅读：https://dev.mysql.com/doc/refman/8.0/en/innodb-read-only-instance.html我怀疑这对于一个普通的应用程序来说是否会带来显著的性能优势。它必须是一个流量非常高的应用程序，因此在InnoDB只读模式下禁用的一些后台线程会导致一些瓶颈。但在这种类型的应用程序中，您自然需要读写模式。