我了解它们为什么很好，但是它们是否用于现实世界的情况？
如果是这样，它们在创建嵌套事务时有多大用处？有什么好处？
例如（一个非常松散的例子），假设我正在创建一个数据库，目的是帮助其他人理解 SQL（假设地）。
所以我需要编写一个脚本来创建数据库、创建模式、为每个模式创建表、为每个模式创建序列、用有效信息填充表，然后结束脚本。
所以在这样做时，我会分解我的批次以依次运行，例如。
use master; go
create databse testdb; go
use testdb; go
create table tbl(XYZ); go
insert into tbl (XYZ)
values (XYZ); go
那么现在，我将在该块的哪个位置使用事务，为什么要嵌套它们？
在此先感谢，感谢您的帮助。
在您无法确保所有语句都成功执行的情况下，事务是一个福音。基本上，情况总是如此。
您实际上无法避免错误：错误、超时、死锁。如果其中一种情况发生，您希望撤消所做的所有修改并报告错误。您不想调试存在的数据损坏问题，因为某些代码只执行了一半。
除了原子性还有其他用途：你可能想隔离事务，检测冲突事务，让冲突事务互相等待，使用锁实现互斥。大多数 trans 用于 DML，而不是 DDL（从实践中说）。一些跨英亩仅用于读取数据库的一致时不变快照。
事务用于确保一组 DML（数据操作语言）语句的一致性。如果某些事情失败（例如，因为您试图创建重复键），整个事务将回滚并且您没有，例如，没有明细行的订单标题。您可以选择使用 ROLLBACK 语句手动回滚。
事务的另一个用途是数据库恢复。如果数据库崩溃，您通常会遇到不一致的情况。恢复操作将回滚不完整的事务。
DDL（数据定义语言）语句（例如 CREATE TABLE）通常在它们自己的事务中执行 - 您不想让数据字典处于不一致的状态。
在您的示例中，唯一可能的事务是围绕 INSERT。执行 INSERT 时将自动创建一个事务。如果您的系统没有打开自动提交并且您未能提交插入，那么您的数据将永远不会进入数据库。
嵌套事务用于复杂情况，您可能希望回滚插入子表并执行其他操作（例如要求额外的用户输入），而不必回滚父表上的事务。
With create db, you can simply drop table if there are errors so you shouldn't need to use transactions but...
they are very useful when you're trying to maintain atomicity across multiple sql statements.