自上周完成任务后还没安排新的任务，烦(qie)躁(xi)。
今天打算安排两篇博客，这是第一篇，另一个是由这个再做的索引案例
1：予備準備
1.以前のデータベースが使用され、CopySQLTableDataテーブルとHierarchyDepartmentテーブルが使用されます
。2.テーブルCopySQLTableDataをバッチで追加する必要があります。
2：練習
1.最初のテストと9つの新しいテストの追加。実行速度に関しては、3秒が経過したように感じられます。これは1秒に3秒です（この比率は詳細に理解できます）。ここでも2つのボタンを開いています。特定の状況を後で見てみましょう。
私たちの素敵なQizai軍は攻撃する準備ができています、そして常に18である私たち
--批量数据
--循环添加数据
declare @i int --声明一个变量
set @i=1 --给变量赋值（初始化）
while @i<10 --循环插入
begin
insert into CopySQLTableData ([Name],Sex,Age,CreationTime,Remark)
values ('长江'+convert(varchar,@i)+'号',0,18,GETDATE(),'SQL批量新增-第一轮');
set @i=@i+1
end
GO
2.最初に実行プランを確認します。ここでは、9つのinsertステートメントがオーバーヘッドを共有しているため、簡単に理解できます
。3。主にI / OとCPUのオーバーヘッドを確認します
。4。次に、別のクライアントの統計を確認します。私たちが簡単に知って理解する必要があるのはこれら3つ、他は無意味で、理解できないものがあります...、18は挿入の9と@iの値です。9は挿入の効果です。以下の19は18 + 9 + @ i初期化;最後の3つは3ウェイハンドシェイクである必要があります（エラーが発生した場合は修正してください！[一本经.jpg]）
さらに、このクエリテスト1のヘッダーは、最初の実行のデータを示します。コードが再度実行されると、クエリテスト2があり、データの比較があります。以下を見てみましょう
。5。ゴシップが終了したら、結果を見てみ
ましょう。3：テスト後、正式なマスサイクル挿入を実行します。今度は100を追加しますケース
1の場合。42分の実行後、まだ待つことができません...
この実行にうんざりしています。CPU比は16〜17（I7〜9750H、6コア、12スレッド）です。停止後、0.1〜0.3割合... このデータ量の慣習は、通常、何気なく行うことではありません（データベースに切り替えている間、10秒間のフリーズがありました）
今回はどれだけのデータが実行されたかを見てみましょう。
…たった1.5kですか？？？間違いはありませんか？（平均速度は1秒あたり2 ......
2.問題を探し
ます
。実行されているクライアントを確認します。青色の1つはCOUNT関数を実行しています。赤色の1つは、追加した新しいデータですか、それとも私はそれを信じられないのですか？I / O効率が低すぎるため、高効率のアプローチ
3.データを追加する時間を
確認します。最初の速度はまだ問題ないことがわかります。1秒あたり10程度のデータが挿入されますが、18秒は少ない
ため、後の期間の2分目は前の2分ほど良くありません。 1秒あたりの挿入数は理論的には当てはまりません
。4 。データベースは何かによって制限されていますか？？
それが問題かどうかはわかりません。助けを求めて大勢の人が通りかかっています。[お願いします] [お願いします]
4.新しい方法
を見つける続行するには...予期しない問題、私はそれを解決する必要があり
ます。また、[狗头保命]でインデックス付けされたブログも、何百万ものデータが正式に追加されるまで遅延することを書きました。
加油ヾ(◍°∇°◍)ﾉﾞ
这是一个失败的方法，但是一篇成功的博客，让我认识到了理论与实践的差距
实践是检验真理的唯一标准 ！！！！