事务中的隔离级别
我想知道达到事务隔离级别的最佳方法是什么？ 这是可用隔离级别的一个很好的链接。
Blockquote 如果有人可以解释事务的各种隔离级别，那就太好了
I want to know that what is the best way to arrive at the isolation level of the transaction?
This is a good link of the available ISOLATION levels.
Blockquote It will be nice if someone can explain the various isolation levels of a transaction
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
更新：澄清并更正了解释。
隔离级别仅表明您的事务有多少受到其他并发事务的影响。 隔离级别越高，受影响越小。
这些努力将体现在 CPU 负载、内存负载，或许还有提交延迟上。 此外，在较高的隔离级别中，写入冲突的可能性更大，这可能意味着您必须中止事务并重试整个操作。 （这仅影响执行更新或插入的事务，而不影响仅执行选择的事务。）
一般来说，经验法则是使用为应用程序提供所需一致性的最低级别。
读提交模式提供的部分事务隔离对于许多应用程序来说已经足够了，并且该模式快速且使用简单； 然而，这并不足以满足所有情况。 执行复杂查询和更新的应用程序可能需要比读提交模式提供的更严格一致的数据库视图。
可序列化模式严格保证每个事务都能看到完全一致的数据库视图。 然而，当并发更新无法维持串行执行的假象时，应用程序必须准备好重试事务。 由于重做复杂事务的成本可能很高，因此仅当更新事务包含足够复杂的逻辑以至于它们可能在读提交模式下给出错误答案时才建议使用可序列化模式。 最常见的是，当事务执行多个必须看到相同数据库视图的连续命令时，需要串行化模式。
( http://www.postgresql.org/docs/8.4/interactive /transaction-iso.html 非常好。）
Update: Clarified and corrected explanation.
Isolation levels just indicate how much of your transaction is affected by other concurrent transactions. The higher the isolation level, the less affected it is.
The effort will be made manifest in cpu load, memory load, and perhaps commit latency. In addition, write conflicts can be more likely in higher isolation levels, which may mean that you have to abort your transaction and retry the whole thing. (This only affects transactions that perform updates or inserts, not transactions which only perform selects.)
In general, the rule of thumb is to use the lowest level that gives your application the consistency it needs.
The partial transaction isolation provided by Read Committed mode is adequate for many applications, and this mode is fast and simple to use; however, it is not sufficient for all cases. Applications that do complex queries and updates might require a more rigorously consistent view of the database than Read Committed mode provides.
The Serializable mode provides a rigorous guarantee that each transaction sees a wholly consistent view of the database. However, the application has to be prepared to retry transactions when concurrent updates make it impossible to sustain the illusion of serial execution. Since the cost of redoing complex transactions can be significant, serializable mode is recommended only when updating transactions contain logic sufficiently complex that they might give wrong answers in Read Committed mode. Most commonly, Serializable mode is necessary when a transaction executes several successive commands that must see identical views of the database.
( http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html is very nice. )
如果您不确定隔离级别的差异，请坚持使用默认值。 改变级别可能会产生特殊的副作用。 99% 的应用程序都可以使用默认设置。
我认为默认值因每个 JDBC 驱动程序而异，尽管像 JPA 这样的一些框架可能会强制执行它，但我不记得了。 最常见的默认值是 read_commissed，因为它在事务安全性和并发性之间提供了最佳的通用平衡。 如果您选择不同的隔离级别，您就会牺牲安全性或并发性，并且您必须意识到折衷方案。
If you're not sure about the differences in isolation levels, then stick to the default. Changing the level can have peculiar side-effects. 99% of applications are fine with the default.
The default I think varies with each JDBC driver, although some frameworks like JPA may enforce it, I can't recall offhand. The most common default is read_committed, because it gives the best general-purpose balance between transactional safety and concurrency. If you pick a different isolation level, you sacrifice either safety or concurrency, and you have to be aware of the compromise.
事务隔离级别旨在解决并发事务中的数据读取问题（当在一个事务中，我们读取另一个事务同时更改的相同数据时）。
有 4 个隔离级别。 每项解决1个相关问题+前面所有级别的问题：
Transaction Isolation Levels are about solving data reading problems in concurrent transactions (when, within one transaction, we read the same data that another transaction changes at the same time).
There are 4 isolation levels. Each solves 1 related problem + the problems of all previous levels:
这到底是什么问题？！
隔离级别定义 DBMS 使用的锁类型和锁粒度。 锁定在 DBMS 环境中至关重要，因为事务可能由许多用户同时执行。 更高的事务隔离（例如 SERIALIZABLE）更安全（您可以潜在地消除脏读和幻像更新），但会受到惩罚，因为序列化事务会限制并发性，从而妨碍可扩展性。
该怎么办？ 构建应用程序，以便在绝对需要时明智地使用序列化事务，从而逻辑限制“坏数据”的可能性，但不会不必要地妨碍并发性。
What the heck is the question?!
Isolation levels define the lock type and lock granularity used by the DBMS. Locking is essential in the context of DBMS's, as transactions are executed concurrently, by potentially many users. Higher transaction isolation--such as SERIALIZABLE--is safer--you can potentially eliminate dirty reads and phantom updates--but impose a penalty as serialized transactions limit concurrency and therefore preclude scalability.
What to do? Architect the application such that the logic limits the possibility of "bad data" by judiciously using serialized transactions when they're absolutely needed, but not such that concurrency is unnecessarily hampered.