为什么需要回滚？
为什么回滚如此重要？
是为了防止数据（如 SQL DB 中的数据）处于不一致状态吗？
如果是这样，那么数据“存储”（SQL DB 或其他什么）首先是如何导致损坏状态的呢？
是否存在不需要“回滚”的数据存储机制？
Why are rollbacks so important?
Is it to prevent data (like data in a SQL DB) from being in an inconsistent state?
If so, how comes the data "store" (the SQL DB or whatever) made it possible in the first place to become in a corrupt state?
Are there data storage mechanisms that don't have a need for "rollbacks"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果数据库操作期间出现任何类型的错误，回滚非常重要。在数据库服务器崩溃或修改数据库内容的应用程序中引发严重异常的情况下，它们确实可以挽救局面。当执行重要的数据库操作（即更新、插入等）并且过程在中间中断时，将很难跟踪哪些操作成功，并且之后数据库的使用将非常复杂。
“存储”本身通常没有内置的一致性控制机制——这正是我们使用回滚和事务的原因。这可以被视为一种“实时备份”机制。
Rollbacks are important in case of any kind of errors appearing during database operational. They can really save the day in case of database server crashes or a critical exception is thrown in an application that modifies contents of DB. When a significant DB operation is performed (i.e. updates, inserts, etc.) and the process is broken in the middle, it would be very hard to trace which operations were successful and usage of DB afterward would be very complicated.
The "store" itself does not generally have a built-in mechanism for consistency control - this is exactly why we use rollbacks and transactions. This can be perceived as a sort of 'live backup' mechanism.
在某些情况下，当您需要在许多相关表中插入/更新数据时 - 如果您没有事务逻辑，那么过程中间的任何错误都可能导致数据不一致。
简单的例子。假设您需要将订单标题数据插入订单表，并将订单行插入行表。您插入订单标题，读取身份，开始插入订单行 - 但无论出于何种原因，第二次插入都会失败。从这种情况中恢复的唯一可靠方法是回滚第一个插入 - 显式（当与数据库的连接处于活动状态时）或隐式（当链接断开时）。
There are cases, when you need insert/update data in many related tables - if you didn't have transactional logic, then any errors somewhere in middle of process could make data inconsistent.
Simple example. Say you need to insert both order header data into orders table and order lines into lines table. You insert order header, read identity, start inserting order lines - but this second insert fails on whatever reason. Only reliable way to recover from this situation is to rollback first insert - either explicitly (when your connection to db is alive) or implicitly (when link is gone down).