通常我认为好的做法是把READ COMITTED隔离模式做为默认，对于应用程序或者transactions 有必要就改成REPEATABLE READ。
READ UNCOMMITTED – 我觉得这是最难理解的隔离模式（悲催的只有2条文档），只描述了它的逻辑观点。如果你使用了这种隔离模式，你会看到数据控中所有发生的变化，即使是那些还没被提交的transactions 。这种隔离模式一种好的用例是：你能“watch”到大规模的有脏读（dirty reads）的UPDATE 语句，显示了哪行被改变了，哪些没有改变。
如果transaction 事务在运行的时候出错了，那么这个声明会显示还没被提交的和可能没被提交的变化，所以使用这个模式要小心为妙。有一些用例虽然不需要我们100%准确的数据，在这种情况下，这种模式就变得非常方便。
那么，从性能角度来看，如何体现READ UNCOMMITTED？理论上，InnoDB 可以清除行版本，在READ UNCOMMITTED模式下即便是该语句已经开始执行之后，也可以创建。在实践中，由于一个bug或者一些复杂实现的细节做不到，语句开始仍然是行版本。所以，如果你在READ UNCOMMITTED声明中运行很长的SELECT，你会得到大量的行版本创建信息，就像你用了READ COMMITTED。No win here。
从SELECT方面还有一个重要的win - READ UNCOMMITTED隔离模式意味着InnoDB 不需要去检查旧的行版本 - 最后一行总是对的，这会使得性能有明显的改善，尤其是当undo空间已经在磁盘上溢出，查找旧的行版本会造成大量的IO读写。
也许上面这个select avg(k) from sbtest1;是我能找到的最好的查询例子了，能与之类似的更新工作量。假使READ UNCOMMITTED隔离模式在一分钟左右完成，我认为在READ COMMITTED隔离模式下没有完成过，因为新索引条目插入的速度要比扫描速度快。
最后思考：正确的使用InnoDB 隔离模式，能够让您的应用程序得到最佳性能。你得到的好处可能不同，在某些情况下，也可能没什么区别。关系到InnoDB 的历史版本，似乎好有好多工作要做，我希望在未来的MySQL中能解决。
