我正在开发一个具有典型CRUD网络使用模式的网站：类似于用户创建/更新内容和其他用户阅读内容的博客或论坛。
在这种情况下，似乎可以将数据库的隔离级别设置为“ Read Uncommitted ”（脏读）。我对“Read Uncommitted”的一般缺点的理解是，读者可能会读取稍后将被回滚的未提交数据。
在CRUD博客/论坛使用模式中，是否会有任何回滚？即使有，读取未提交的数据是否有任何重大问题？
现在我没有使用任何复制，但是将来如果我想使用复制（基于行，而不是基于语句），“Read Uncommitted”隔离级别会阻止我这样做吗？
你怎么看？有人试过在他们的RDBMS上使用“Read Uncommitted”吗？答案 0 :(得分：3)
使用read-uncommitted和binlogging（复制需要）时，MySQL 5.1更严格 - 因此您可能会在默认隔离级别REPEATABLE READ中获得的一些简单更新/删除语句中出现错误。我见过简单的PK更新，例如：
更新foo set bar = 1，其中id = 1234;
错误： mysql_real_query错误1598消息：二进制 记录不可能。消息：InnoDB中的事务级别“READ-UNCOMMITTED” 对于binlog模式'STATEMENT'
是不安全的因此，您必须准备好在修改数据时切换回可重复读取，或者使用单独的读取和写入连接以及它们自己的隔离级别来处理此问题。如果您的项目需要扩展和复制，后者可以派上用场，因此您可以将select发送到只读从站并在主站上写入。
OTOH，如果不严格需要一致读取，则使用read-uncommitted进行读取可能是一个真正的好处，因为Innodb具有较少的锁定。关于是否可以回滚的问题，我认为你是最好的人告诉我们，因为你是编码的人:)。
答案 1 :(得分：2)
此隔离级别意味着您可能会读取不一致的数据。没有保证您读取的数据来自数据库的一致视图。
这是一个问题还是不是MySQL问题，而是一个应用程序问题，它涉及评估使用/返回不一致数据的风险。
在互联网银行应用程序上，这是不可能的。在游戏中它可能没问题。这取决于。
我已经使用了“read uncommitted”和复制，并且没有任何问题。