【发布时间】:2011-04-20 11:08:36
【问题描述】:
我们在什么场景下使用SERIALIZABLE隔离级别?我在网站上看到一些答案说,当您希望交易完全隔离时,我们通常会这样做。
根据您自己的经验,我想知道的是,当您在自己的项目中使用它/或者您已经看到它在其他项目中使用时,哪些具体要求没有得到满足其他隔离级别?
【问题讨论】:
标签: database isolation-level transaction-isolation
我们在什么场景下使用SERIALIZABLE隔离级别?我在网站上看到一些答案说,当您希望交易完全隔离时,我们通常会这样做。
根据您自己的经验,我想知道的是,当您在自己的项目中使用它/或者您已经看到它在其他项目中使用时,哪些具体要求没有得到满足其他隔离级别?
【问题讨论】:
标签: database isolation-level transaction-isolation
SERIALIZABLE 在您构建需要多个查询的复杂报表时很有用。
在READ COMMITTED 或REPEATABLE READ 中,查询可以看到在事务开始和它们运行之间所做的更改。
pg_dump,PostgreSQL 转储实用程序,通过发出SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 启动它的工作,以保证被转储的数据库的状态将是该实用程序运行时的状态,以及随后对数据库的更改无法干扰转储。
【讨论】:
如果您想简单地证明并发负载的正确性,SERIALIZABLE 事务很有用。由于 SQL 标准(自 SQL-92 起)中对可序列化事务隔离级别的定义是,任何并发的可序列化事务集的行为必须与某些串行(一次一个)执行顺序一致,任何单独运行时可以显示做正确事情的事务,将作为任何可序列化事务组合的一部分做正确的事情。
这种保护是有代价的——有时必须阻止或回滚事务以重试以确保可序列化的事务隔离,并且必须跟踪信息以确定何时需要采取此类操作。在一些事务类型和开发人员数量较少的开发环境中,使用不太严格的隔离级别并在应用程序代码中显式管理竞争条件通常更具成本效益。一旦您有数十名程序员处理具有数百个表和数万种事务类型的模式,那么在不太严格的隔离级别下,确定存在竞争条件的成本可能会变得难以承受,并且使用可序列化事务通常会变得更具成本效益.
目前,提供可序列化事务的最常用方法是严格的两阶段锁定 (S2PL),它依赖于一直保持到每个事务结束的阻塞锁,以及通过回滚来打破死锁的死锁检测。在写入争用非常少的负载中,可以使用乐观并发控制 (OCC)。它在事务过程中跟踪“读取集”,并在任何其他事务修改读取集时回滚。一些数据库产品将快照隔离称为可序列化,尽管它实际上并没有提供 SQL 标准所要求的保证。一种称为可序列化快照隔离(SerializableSI 或 SSI)的新技术首次在 2008 ACM SIGMOD 上发表的学术论文中进行了描述,并在 PostgreSQL 9.1 及更高版本中使用。它使用快照隔离和跟踪读写依赖模式来确定何时必须取消事务。还有其他技术在生产中很少见。每一个都有自己的优点和缺点,为这样的问题提供了不同的收支平衡点。
【讨论】: