最後に、@ table変数と#tempテーブルのパフォーマンスを比較するためのテストスクリプトがあります。私はそれを正しく設定したと思います-パフォーマンスタイミングはDELETE/TRUNCATEコマンドのoutsideから取得されます。私が得ている結果は次のとおりです(ミリ秒単位の時間)。
@Table Variable #Temp (delete) #Temp (truncate)
--------------- -------------- ----------------
5723 5180 5506
15636 14746 7800
14506 14300 5583
14030 15460 5386
16706 16186 5360
私が正気であることを確認するために、これは、CURRENT_TIMESTAMP(別名GetDate()
)がバッチではなくステートメントの時点で取得されることを示しているため、TRUNCATE/DELETEとSET @StartTime = CURRENT_TIMESTAMP
との相互作用はありません。ステートメント。
select current_timestamp
waitfor delay '00:00:04'
select current_timestamp
-----------------------
2012-10-21 11:29:20.290
-----------------------
2012-10-21 11:29:24.290
DELETEを使用してテーブルをクリアした場合、最初の実行と後続の実行の間のジャンプは非常に一貫しています。 [〜#〜] delete [〜#〜]の理解で何が欠けていますか?これを何度も繰り返し、順序を入れ替え、tempdbのサイズを大きくする必要がないようにしました。
CREATE TABLE #values (
id int identity primary key, -- will be clustered
name varchar(100) null,
number int null,
type char(3) not null,
low int null,
high int null,
status smallint not null
);
GO
SET NOCOUNT ON;
DECLARE @values TABLE (
id int identity primary key clustered,
name varchar(100) null,
number int null,
type char(3) not null,
low int null,
high int null,
status smallint not null
);
DECLARE @ExecutionTime TABLE( Duration bigINT )
DECLARE @StartTime DATETIME, @i INT = 1;
WHILE (@i <= 5)
BEGIN
DELETE @values;
DBCC freeproccache With NO_InfoMSGS;
DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate()
/****************** measured process ***********************/
INSERT @values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;
/**************** end measured process *********************/
INSERT @ExecutionTime
SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP)
SET @i += 1
END -- WHILE
SELECT DurationInMilliseconds = Duration FROM @ExecutionTime
GO
-- Temporary table
DECLARE @ExecutionTime TABLE( Duration bigINT )
DECLARE @StartTime DATETIME, @i INT = 1;
WHILE (@i <= 5)
BEGIN
delete #values;
-- TRUNCATE TABLE #values;
DBCC freeproccache With NO_InfoMSGS;
DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate()
/****************** measured process ***********************/
INSERT #values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;
/**************** end measured process *********************/
INSERT @ExecutionTime
SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP)
SET @i += 1
END -- WHILE
SELECT DurationInMilliseconds = Duration FROM @ExecutionTime
GO
DROP TABLE #values
SET NOCOUNT OFF;
この違いは、オブジェクトがB +ツリーの場合にのみ適用されるようです。テーブル変数のprimary key
を削除してヒープにすると、次の結果が得られます
2560
2120
2080
2130
2140
しかし、PKを使用すると、テストで同様のパターンが見つかり、以下の典型的な結果も得られました。
+--------+--------+---------+-------------------+
| @table | #table | ##table | [permanent_table] |
+--------+--------+---------+-------------------+
| 2670 | 2683 | 9603 | 9703 |
| 6823 | 6840 | 9723 | 9790 |
| 6813 | 6816 | 9626 | 9703 |
| 6883 | 6816 | 9600 | 9716 |
| 6840 | 6856 | 9610 | 9673 |
+--------+--------+---------+-------------------+
私の理論では、ローカルの一時B +ツリーへの一括挿入を行うときに、ページがまだ割り当てられていない場合にのみ適用される最適化がいくつかあります。
これは以下の観察に基づいています。
テストコードのさまざまなバージョンを実行しているとき、このパターンは@table_variables
および#temp
テーブルでのみ見られました。 tempdb
にも##
テーブルにも永続テーブルはありません。
パフォーマンスを低下させるために、テーブルに大量の行を追加したり削除したりする必要はありません。単一の行を追加してそこに残すだけで十分です。
TRUNCATE
は、テーブルからすべてのページの割り当てを解除します。 DELETE
を指定しても、テーブルの最後のページは割り当て解除されません。
VS 2012プロファイラーを使用すると、より高速なケースではSQL Serverが別のコードパスを使用することがわかります。時間の36%がsqlmin.dll!RowsetBulk::InsertRow
で費やされているのに対し、遅いケースではsqlmin.dll!RowsetNewSS::InsertRow
で費やされた時間の61%が費やされています。
ランニング
SELECT *
FROM sys.dm_db_index_physical_stats(2,OBJECT_ID('tempdb..#values'),1,NULL, 'DETAILED')
削除が戻った後
+-------------+------------+--------------+--------------------+
| index_level | page_count | record_count | ghost_record_count |
+-------------+------------+--------------+--------------------+
| 0 | 1 | 0 | 1 |
| 1 | 1 | 1 | 0 |
| 2 | 1 | 1 | 0 |
+-------------+------------+--------------+--------------------+
トレースフラグ610を有効にする を使用すると、時間のずれを多少減らすことができることがわかりました。
これにより、後続の挿入のログ記録の量が大幅に削減されました(350 MBから103 MBに減少しました)値)ですが、2回目以降の@table
、#table
の場合のタイミングの改善はわずかで、ギャップはまだ残っています。トレースフラグにより、他の2つのテーブルタイプへの挿入の一般的なパフォーマンスが大幅に向上しました。
+--------+--------+---------+-------------------+
| @table | #table | ##table | [permanent_table] |
+--------+--------+---------+-------------------+
| 2663 | 2670 | 5403 | 5426 |
| 5390 | 5396 | 5410 | 5403 |
| 5373 | 5390 | 5410 | 5403 |
| 5393 | 5410 | 5406 | 5433 |
| 5386 | 5396 | 5390 | 5420 |
+--------+--------+---------+-------------------+
トランザクションログを調べたところ、空のローカルテンポラリテーブルに対する最初の挿入がさらに最小限に記録されているように見えた(96 MB)。
特に、これらのより高速な挿入は、低速の場合に657
を超えるトランザクションと比較して、LOP_BEGIN_XACT
トランザクション(LOP_COMMIT_XACT
/10,000
ペア)のみでした。特にLOP_FORMAT_PAGE
操作は大幅に削減されたようです。遅い場合は、高速な場合の10,270
のみのエントリと比較して、テーブルの各ページ(約4
)のトランザクションログエントリがあります。
3つのケースすべてで使用されたログは次のとおりです(テキストの量を減らすためにシステムベーステーブルの更新のログレコードを削除しましたが、それらはまだ合計に含まれています)。
@table_var
に対するログの最初の挿入(96.5 MB)+-----------------------+----------+----------------------------------------------+---------------+---------+
| Operation | Context | AllocUnitName | Size in Bytes | Cnt |
+-----------------------+----------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_XACT | LCX_NULL | NULL | 83876 | 658 |
| LOP_COMMIT_XACT | LCX_NULL | NULL | 34164 | 657 |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL | NULL | 120 | 3 |
| LOP_FORMAT_PAGE | LCX_HEAP | dbo.#531856C7 | 84 | 1 |
| LOP_FORMAT_PAGE | LCX_IAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 84 | 1 |
| LOP_FORMAT_PAGE | LCX_IAM | dbo.#531856C7 | 84 | 1 |
| LOP_FORMAT_PAGE | LCX_IAM | Unknown Alloc Unit | 84 | 1 |
| LOP_HOBT_DDL | LCX_NULL | NULL | 216 | 6 |
| LOP_HOBT_DELTA | LCX_NULL | NULL | 320 | 5 |
| LOP_IDENT_NEWVAL | LCX_NULL | NULL | 100240000 | 2506000 |
| LOP_INSERT_ROWS | LCX_HEAP | dbo.#531856C7 | 72 | 1 |
| LOP_MODIFY_ROW | LCX_IAM | dbo.#531856C7 | 88 | 1 |
| LOP_MODIFY_ROW | LCX_PFS | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 158592 | 1848 |
| LOP_MODIFY_ROW | LCX_PFS | dbo.#531856C7 | 80 | 1 |
| LOP_MODIFY_ROW | LCX_PFS | Unknown Alloc Unit | 216016 | 2455 |
| LOP_SET_BITS | LCX_GAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 84360 | 1406 |
| LOP_SET_BITS | LCX_GAM | Unknown Alloc Unit | 147120 | 2452 |
| LOP_SET_BITS | LCX_IAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 84360 | 1406 |
| LOP_SET_BITS | LCX_IAM | Unknown Alloc Unit | 147120 | 2452 |
| Total | NULL | NULL | 101209792 | 2519475 |
+-----------------------+----------+----------------------------------------------+---------------+---------+
+-----------------------+--------------------+----------------------------------------------+---------------+---------+
| Operation | Context | AllocUnitName | Size in Bytes | Cnt |
+-----------------------+--------------------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_CKPT | LCX_NULL | NULL | 96 | 1 |
| LOP_BEGIN_XACT | LCX_NULL | NULL | 1520696 | 12521 |
| LOP_COMMIT_XACT | LCX_NULL | NULL | 651040 | 12520 |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL | NULL | 40 | 1 |
| LOP_DELETE_SPLIT | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 2160 | 36 |
| LOP_END_CKPT | LCX_NULL | NULL | 136 | 1 |
| LOP_FORMAT_PAGE | LCX_HEAP | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 859236 | 10229 |
| LOP_FORMAT_PAGE | LCX_IAM | Unknown Alloc Unit | 84 | 1 |
| LOP_FORMAT_PAGE | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 3108 | 37 |
| LOP_HOBT_DDL | LCX_NULL | NULL | 648 | 18 |
| LOP_HOBT_DELTA | LCX_NULL | NULL | 657088 | 10267 |
| LOP_IDENT_NEWVAL | LCX_NULL | NULL | 100239960 | 2505999 |
| LOP_INSERT_ROWS | LCX_CLUSTERED | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 258628000 | 2506000 |
| LOP_INSERT_ROWS | LCX_HEAP | dbo.#531856C7 | 72 | 1 |
| LOP_INSERT_ROWS | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 1042776 | 10302 |
| LOP_MODIFY_HEADER | LCX_HEAP | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 859236 | 10229 |
| LOP_MODIFY_HEADER | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 3192 | 38 |
| LOP_MODIFY_ROW | LCX_IAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 704 | 8 |
| LOP_MODIFY_ROW | LCX_PFS | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 934264 | 11550 |
| LOP_MODIFY_ROW | LCX_PFS | Unknown Alloc Unit | 783984 | 8909 |
| LOP_SET_BITS | LCX_GAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 76980 | 1283 |
| LOP_SET_BITS | LCX_GAM | Unknown Alloc Unit | 534480 | 8908 |
| LOP_SET_BITS | LCX_IAM | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 | 76980 | 1283 |
| LOP_SET_BITS | LCX_IAM | Unknown Alloc Unit | 534480 | 8908 |
| LOP_SHRINK_NOOP | LCX_NULL | NULL | 32 | 1 |
| LOP_XACT_CKPT | LCX_NULL | NULL | 92 | 1 |
| Total | NULL | NULL | 367438748 | 5119297 |
+-----------------------+--------------------+----------------------------------------------+---------------+---------+
+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
| Operation | Context | AllocUnitName | Size in Bytes | Cnt |
+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_CKPT | LCX_NULL | NULL | 192 | 2 |
| LOP_BEGIN_XACT | LCX_NULL | NULL | 1339796 | 11099 |
| LOP_BULK_EXT_ALLOCATION | LCX_NULL | NULL | 20616 | 162 |
| LOP_COMMIT_XACT | LCX_NULL | NULL | 577096 | 11098 |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL | NULL | 40 | 1 |
| LOP_DELETE_SPLIT | LCX_INDEX_INTERIOR | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 2160 | 36 |
| LOP_END_CKPT | LCX_NULL | NULL | 272 | 2 |
| LOP_FORMAT_PAGE | LCX_BULK_OPERATION_PAGE | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 863520 | 10280 |
| LOP_FORMAT_PAGE | LCX_IAM | Unknown Alloc Unit | 84 | 1 |
| LOP_FORMAT_PAGE | LCX_INDEX_INTERIOR | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 3108 | 37 |
| LOP_HOBT_DELTA | LCX_NULL | NULL | 666496 | 10414 |
| LOP_IDENT_NEWVAL | LCX_NULL | NULL | 100239960 | 2505999 |
| LOP_INSERT_ROWS | LCX_CLUSTERED | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 23544 | 218 |
| LOP_INSERT_ROWS | LCX_HEAP | dbo.#719CDDE7 | 72 | 1 |
| LOP_INSERT_ROWS | LCX_INDEX_INTERIOR | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 1042776 | 10302 |
| LOP_MODIFY_HEADER | LCX_BULK_OPERATION_PAGE | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 780216 | 10266 |
| LOP_MODIFY_HEADER | LCX_HEAP | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 1718472 | 20458 |
| LOP_MODIFY_HEADER | LCX_INDEX_INTERIOR | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 3192 | 38 |
| LOP_MODIFY_ROW | LCX_IAM | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 704 | 8 |
| LOP_MODIFY_ROW | LCX_PFS | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 114832 | 1307 |
| LOP_MODIFY_ROW | LCX_PFS | Unknown Alloc Unit | 231696 | 2633 |
| LOP_RANGE_INSERT | LCX_NULL | NULL | 48 | 1 |
| LOP_SET_BITS | LCX_GAM | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 77100 | 1285 |
| LOP_SET_BITS | LCX_GAM | Unknown Alloc Unit | 157920 | 2632 |
| LOP_SET_BITS | LCX_IAM | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 | 77100 | 1285 |
| LOP_SET_BITS | LCX_IAM | Unknown Alloc Unit | 157920 | 2632 |
| LOP_XACT_CKPT | LCX_NULL | NULL | 92 | 1 |
| Total | NULL | NULL | 108102960 | 2602218 |
+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
観察と推測。 。 。
一部のシステムでは、CURRENT_TIMESTAMPが現在のトランザクションの開始時刻になるように定義されています。クイック検索では、CURRENT_TIMESTAMPがSQL Serverでどのように動作するかについての明確なドキュメントは見つかりませんでした。ただし、SQL Serverの既定のモードはトランザクションの自動コミットであり、ここにはBEGIN TRANSACTIONがないため、oughtがINSERTステートメントの直前の時間になります。 (DELETEステートメントは自動的にコミットする必要があり、CURRENT_TIMESTAMPがSQL Serverで機能する方法に関係なく、自動コミットされたトランザクションを使用している場合、DELETEステートメントとは何の関係もありません。)
最初の反復では、DELETEステートメントには実際に行うべき作業はなく、ログに記録する個別の行はありません。多分オプティマイザはそれを知っており、それが最初の反復の時間を短縮しています。 (削除する行がないこと、およびログする個々の行がないことの組み合わせ。)
削除する前に挿入することでそれをテストできます(私は思う)。