针对数据库事务隔离级别的讨论，期待你的参与！

will009

@lyhabc
学习了，我理解得还不够深刻

第一最寂寞i

安全与性能都是相对的，你的安全性做的越好，性能就会变差，高效的性能，方便数据的读取，那么你得安全设置就不是那么好，Oracle不支持READ UNCOMMITTED和REPEATABLE READ，肯定出于的目的就是secure，毕竟是专业的DB公司，对安全性的要求肯定要达到专业水平，说白了，就是宁愿牺牲时间或者效率也要保证安全。我还是比较支付ORACLE的观念

lyhabc

@第一最寂寞i
支持和不支持有什么所谓呢，让用户选择就可以了

第一最寂寞i

回复 13# lyhabc
涉及到大库的安全用户的选择性基本没有


   

liguangyi

讨论话题
1、Oracle不支持READ UNCOMMITTED和REPEATABLE READ ，大家觉得有道理吗？

觉得可以接受。
READ UNCOMMITTED 会出现脏读，日常应用中极少使用这种方式。
REPEATABLE READ 每次读都是该事务起始时的数据状态快照，虽然可以重复读但数据可能已不是系统中最新的，实际也是脏读的一种，如果要作以此更新，仍然会导致其它事务的更新丢失。

2、默认事务隔离级别，大家认为使用四种隔离级别哪一种隔离级别作为默认事务隔离级别是最好的，好在哪，其他的隔离级别差在哪？

通常情况下，READ COMMITTED 就很好了。REPEATABLE READ 只有在长时间只读事务中，例如数据分析OLAP之类有优势，但通常很少在线上直接作这个吧。其它的或者脏读，或者性能不可接受。

3、事务隔离级别越高，性能越差这个观点虽然在《Transaction Processing》书中说性能相差不大，但是实际上在数据库实现上持有锁的时间是增加了的，持有锁的时间增加意味着并发的降低，大家是认同《Transaction Processing》书中的观点吗，请说出认同或者不认同的理由。

隔离级别越高，性能必然越差。如果只采用SERIALIZABLE 级别，对于大型数据库就是作死。慢事务会拖死其它事务的。数据库本来就是高cpu负载高IO的应用，现在通常的4CPU32核心都有时cpu满载，如果顺序依次执行事务，不能充分利用多核优势，其性能肯定无法接受。

4、数据库是否需要学SQL Server提供一个打开和关闭MVCC的开关，让用户自己决定是否使用MVCC，进而让用户来承担MVCC所带来的副作用的风险，而不是默认只能用MVCC。

没必要。SQL Server新版本没用过，但以前的版本对sql标准的兼容很差。如果学习数据库，可以考虑postgresql。MVCC本身并没有什么副作用，是用户使用的方法不对。
防止更新覆盖有多种方法。比如1、最原始的锁表锁库，2、记录上加排他写锁 select for update，3、记录中设置timestamp字段，update时检查时间戳是否变化，变化了则重新读，4、应用本身将有冲突的更新串行化处理。

lyhabc

@liguangyi
请问pgsql您用得很熟吗

gta

markmarkmarkmarkmark

西道古边

路过了～～～～～～～～～～～··

lyhabc

@柴银健
谢谢！