事务的隔离性一般分为4个级别：
1. Read Uncommitted 未授权读取，实质上该级别允许读取未提交的数据，就是允许脏读。如果一个事务A读取了一条记录 r，并修改了该记录，事务A尚未提交时，事务B读取了r，如果事务A最后回滚了(因某种原因)，那么事务B读了一条无效的记录。[1]给的例子，如果事务A对某一个值进行了 加1 操作 10 次，事务B能读取其中的中间值 2,3,4… ，这一系列中间值的读取就是未授权读取。
2. Read Committed 授权读取，也叫只读已提交数据，不允许脏读了。如果事务A对读取了一条记录 r1，并修改了该记录为 r2，事务A尚未提交时，事务B读取该记录，依然是原来的 r1，当事务A committed以后，事务B才能读取事务A修改后的值 r2，这就是授权读取，不会读中间数据，只读最终提交的数据。
但是，这有个问题，不可重复读问题（在一个事务范围内，执行2个相同的查询，查询的结果不同，因为有其他事务update了数据）。事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变 [2]，造成了不可重复读。
3. Repeatable Read 可重复读，该隔离界别是多次读取同一条记录时，读取结果相同。这是禁止了不可重复读，实质上，当事务A读取记录r1时，不允许其他事务修改 r1，如果修改，需要等待事务A处理结束。说个额外有趣的，当事务A在修改数据时，发生了查询怎么办？实际应用中，是给数据和查询加了一个SCN (System change number)，简单的说，为每一个查询添加一个时间戳，然后对比记录的时间戳，详见 [3]。
但是还是有问题，无法解决幻读问题，比如事务A 将 T表 中所有工资不到 10000元 的员工的工资改为10000元，在事务A执行结束尚未提交时，事务B又插入了一条（或删除操作）工资不满10000元的员工记录，然后再提交事务A，事务B。事务A好像发生了幻觉，没有操作成功一样，这是因为“可重复读”锁定的是，已经读取的记录，而不是锁定整张表（或者超出读取范围的数据），可重复读限制了事务本身涉及数据的update行为，但是无法限制事务自身以外的数据。我们可以使用表锁或者范围锁。
4. Serializable 串行化，这是最严苛的事务隔离级别。将所有事务串行化执行，简单暴力，直觉低效（但是也看场合）。
实际应用中，更多的是采用乐观锁，去保证数据的一致性，提高效率。最后说一下，乐观锁和悲观锁不是“锁”，以后补充。
并发控制机制
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。
最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时，其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如，放在一个表上的锁限制对整个表的并发访问；放在数据页上的锁限制了对整个数据页的访问；放在行上的锁只限制对该行的并发访问。可见行锁粒度最小，并发访问最好，页锁粒度最大，并发访问性能就会越低。
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[1] 悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的锁定一个对象，限制其他用户的访问，也就是说悲观锁的并发访问性不好。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。 乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。
从数据库厂商的角度看，使用乐观的页锁是比较好的，尤其在影响很多行的批量操作中可以放比较少的锁，从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁，当两个用户同时访问更改位于同一数据页上的相邻两行时，其中一个用户必须等待另一个用户释放锁，这会明显地降低系统的性能。interbase和大多数关系数据库一样，采用的是乐观锁，而且读锁是共享的，写锁是排他的。可以在一个读锁上再放置读锁，但不能再放置写锁；你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。
综上所述：在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.
