Question

我对SQL数据库很有经验，但主要使用Oracle和MySQL。

现在我正在处理SQL Server 2012（Management Studio 2008）并面临一个我无法解释的奇怪行为。

考虑这3个查询和由400k行组成的原始表：

SELECT ID_TARJETA 
INTO [SGMENTIA_TEMP].[dbo].[borra_borra_] 
FROM [DATAMART_SEGMENTIA].[DESA].[CLIENTES]

ALTER TABLE [SGMENTIA_TEMP].[dbo].[borra_borra_] 
  ADD PRIMARY KEY (ID_TARJETA)

SELECT COUNT(*) 
FROM [SGMENTIA_TEMP].[dbo].[borra_borra_]

如果我一个接一个地运行，它运行正常。（总计： ~7秒）。

如果我全部选中并立即运行所有查询，则会运行BAD。（总计： ~60秒）

最后，如果我将所有与事务包装起来，它会再次运行

BEGIN TRANSACTION;

SELECT ID_TARJETA 
INTO [SGMENTIA_TEMP].[dbo].[borra_borra_] 
FROM [DATAMART_SEGMENTIA].[DESA].[CLIENTES]

ALTER TABLE [SGMENTIA_TEMP].[dbo].[borra_borra_] 
ADD PRIMARY KEY(ID_TARJETA)

SELECT COUNT(*) 
FROM [SGMENTIA_TEMP].[dbo].[borra_borra_]

COMMIT;

整个画面对我来说没有意义，考虑到创建交易看起来相当昂贵，第一个场景应该是一个慢的，第二个场景应该更好，我错了吗？

这个问题对我来说非常重要，因为我正在以编程方式（jdbc）构建这类查询包，我需要一种方法来调整其性能。

Answer 1

提供的两个代码段之间仅的区别在于，第一个使用默认交易模式，第二个使用显式交易。

由于SQL Server默认事务模式为自动提交事务，因此每个单独的语句都是事务。

您可以找到有关交易模式here的更多信息。

你可以试试看它是否也能在60秒内运行：

BEGIN TRANSACTION;

SELECT ID_TARJETA 
INTO [SGMENTIA_TEMP].[dbo].[borra_borra_] 
FROM [DATAMART_SEGMENTIA].[DESA].[CLIENTES];

COMMIT;

BEGIN TRANSACTION;

ALTER TABLE [SGMENTIA_TEMP].[dbo].[borra_borra_] 
ADD PRIMARY KEY(ID_TARJETA);

COMMIT;

BEGIN TRANSACTION;

SELECT COUNT(*) 
FROM [SGMENTIA_TEMP].[dbo].[borra_borra_]

COMMIT;

了解SQL Server查询执行和事务

1 个答案: