总是创建交易是一种不好的做法吗？

这取决于您在这里谈论的上下文。如果是更新，那么我强烈建议明确使用 TRANSACTIONS。如果它是一个 SELECT 则 NO（明确）。

但是首先要了解更多信息：sql server 中的所有内容都包含在事务中。

当 session 选项IMPLICIT_TRANSACTIONS是OFF并且您明确指定时begin tran，commit/rollback这通常称为Explicit Transaction。否则你会得到一个自动提交事务。

当 执行在线书籍文章（例如/ / ）中记录的语句类型之一IMPLICIT_TRANSACTIONS时ON，隐式事务会自动启动，并且必须显式提交或回滚。在这种模式下执行 a会增加并启动另一个“嵌套”事务）SELECT``UPDATE``CREATE``BEGIN TRAN``@@TRANCOUNT

要切换您所处的模式，您可以使用

SET IMPLICIT_TRANSACTIONS ON

或者

SET IMPLICIT_TRANSACTIONS OFF

select @@OPTIONS & 2

如果上面返回 2，则您处于隐式事务模式。如果它返回 0，则说明您处于自动提交状态。

在没有必要的情况下创建交易的成本是多少？

需要事务将数据库从一种一致状态转变为另一种一致状态。交易没有成本，因为没有交易的替代品。参考：使用基于行版本控制的隔离级别

即使您使用的是 read_uncommitted 隔离级别。是不好的做法吗？因为它不应该有锁定问题。

READ_UNCOMMITED 隔离级别将根据定义允许脏读，即一个事务将能够看到其他事务所做的未提交更改。这个隔离级别的作用是，它放宽了锁定的开销——获取锁定以保护数据库并发的方法。

您可以在连接/查询级别上使用它，这样它就不会影响其他查询。

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

发现 Jeff Atwood 的一篇有趣的文章，描述了由于就餐哲学家拼图导致的死锁，并描述了 读取提交的快照隔离级别。

编辑：

出于好奇，我做了一些测试，使用 Perfmon 计数器测量对 T-log 的影响，例如 Log Bytes Flushed/Sec、Log Flush Waits/Sec（等待 LOG 刷新发生的每秒提交数），如下图：

示例代码：

create table testTran (id int, Name varchar(8))
go

-- 19 sec
-- Autocommit transaction
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
---------------------------------------------------
-- 2 sec
-- Implicit transaction
SET IMPLICIT_TRANSACTIONS ON
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
COMMIT;
SET IMPLICIT_TRANSACTIONS OFF


----------------------------------------------------
-- 2 sec
-- Explicit transaction
declare @i int
set @i = 0
BEGIN TRAN
WHILE @i < 100000
Begin
INSERT INTO testTran values (1,'Kin Shah')
set @i = @i+1
End
COMMIT TRAN

自动提交事务：（由@TravisGan 高亮编辑）

• 插入耗时 19 秒。
• 由于自动提交，每个自动提交都会将 T-log 缓冲区刷新到磁盘（在突出显示 @TravisGan 之后，我错过了提及）。
• CHECKPOINT 进程将快速完成，因为需要刷新的脏日志缓冲区量会更少，因为它经常安静地运行。

隐式和显式事务：

• 插入耗时 2 秒。
• 对于 EXPLICIT 事务，日志缓冲区只有在它们已满时才会被刷新。
• 与 Autocommit 事务相反，在 EXPLICIT 事务中，CHECKPOINT 过程将花费更长的时间，因为它将有更多的日志缓冲区要刷新（请记住，只有在日志缓冲区已满时才会刷新）。

有一个 DMV sys.dm_tran_database_transactions将返回有关数据库级别事务的信息。

显然，这更像是一种显示影响的简单测试。磁盘子系统、数据库自动增长设置、数据库的初始大小、在同一服务器\数据库上运行的其他进程等其他因素也会产生影响。

从上述测试来看，隐式和显式事务之间几乎没有区别。