ERP的最佳默认事务隔离级别是什么(如果有的话)?

100次中有99次,read committed是正确答案。这确保您只看到其他会话提交的更改(因此,假设您正确设计了事务,则结果是一致的)。但它并没有像可重复读取或可序列化数据库那样增加锁定开销(特别是在非Oracle数据库中)。

有时,您可能希望运行一个报告,在该报告中,您愿意牺牲准确性来提高速度,并设置读取未提交隔离级别。这很少是一个好主意,但它偶尔是一个可以合理接受的解决方案,用于锁定争用问题。

不要忘记快照,它就在SERIALIZABLE下面。

这在很大程度上取决于您如何设计应用程序,简单的答案就是在READ_COMMITTED上运行。

您可以提出一个论点,如果您在设计系统时考虑到它,那么您可以使用READ_UNCOMMITTED作为默认值,并且只在需要时增加隔离级别。无论如何,您的绝大多数事务都会成功,因此读取未提交的数据不会有什么大不了的。

对于SQL Server(可能是最主要的RDBMS),我坚持使用默认值。对于SQL Server,这是读提交的。再多的话,你就开始加重数据库的负担,再少的话,你就有了一致性问题。

ReadUncommitted绝对是大多数论坛中的失败者。然而,使用它的理由超出了经常被指出的“速度与准确性”的问题。

假设你有:

• 事务T1:写入B,读取A,(更多的工作),提交。
• 事务T2:写入A,读取B(更多的工作),提交。

您可以重新编写这些过程来避免这种情况(例如:获取资源总是按字母顺序!)。尽管如此,由于并发用户太多,代码行数万行,这个问题很可能也很难诊断和解决。

• (1) 回滚:不要。这应该是硬件故障、网络故障或程序崩溃时的最后一道防线。

• (2) 使用应用程序锁创建可运行的锁定机制