数据库的Isolation Level真是很容易让人误解

ANSI有Read Uncommitted, Read Committed, Repeatable Read, Serializable 4个Isolation Level, 不过当年数据库没学好，一直没有理解这4个level是怎么回事。

比如Read Committed，我按照字面理解是：第一个人来，Update一条记录，然后不commit; 这个时候第二个人来，Select同一条记录会读到以前的值。(编辑一下：这句应该是对的，错的是下面这个)：自己update的东西自己再去read不就是还没有commit的？那么不就读不到了？

Repeatable Read, 按照字面理解：凡是Select出来的，下次用同样的条件一定Select出来一样的内容。
Serializable, 按照字面理解：transaction严格地一个一个来执行。


但最终发现上面的某些理解大错特错（标个红色，免得有人以为上面是正解 ）。然后问了几个同学，发现有（或有过）类似误解的人还不少。

难道不是吗？

lz说说你的理解，

又仔细查了查，上面写的read committed的理解没错，当时有一个问题是自己update的东西自己再去read不就是还没有commit的？那么不就读不到了？好奇怪，这个想法才是错的。

但是repeatable read和serializable当年的理解确实是错了。repeatable read不是那么repeatable, 第二次read可能产生幻影行。而serializable也不是那么串行，DBMS还是会允许完全无关的transaction继续执行.

lz还是回头好好看看书吧。推荐一本
http://www.china-pub.com/computers/common/info.asp?id=32560

sigh 坏就坏在看书上。
repeatable read和serializable的疑问都是看书解决的，感觉名字没起好。

read committed一直很有疑问（主要是后面写的那个：自己读得到自己没有commit的东西吗？），然后也看书，结果翻错了一页 ，看到repeatable read上面去了，就以为除了这个问题以外，对于read committed似乎的理解似乎都错了，大惊，幸至此发帖，再回头看看，才知道原来翻错页了。

另外一个问题，大家写程序的时候对于事务内部的竞争条件会考虑到什么程度？特别是select出来后面又会被别人改变的情况。

标准是一个样，各个数据库平台的实现还不一样呢，

一般应该是read commited，看数据的竞争情况了，如果只是查看，改了就改了，无所谓，如果要修改，就要看数据一致性要求的程度了。