最適化に関しては、最初にインデックスについて考えることができます。もちろん、インデックスは、データベーステーブルの1つ以上の列の値を並べ替える構造です。データベーステーブルの特定の情報にすばやくアクセスできます。インデックスは、クラスター化インデックスと非クラスター化インデックスに分けられます。クラスター化インデックスには2種類あります。クラスター化インデックスは、データが格納されている物理的な場所の順になっています。非クラスター化インデックスは異なります。クラスター化インデックスは、複数行の取得速度を向上させることができ、非クラスター化インデックスは単一行の取得に必要です。データベースの機能に応じて、データベースデザイナーでは、一意のインデックス、主キーインデックス、クラスター化インデックスの3つのインデックスを高速に作成できます。まあ、私はインデックスについても少し知っているので、ここではあまり触れませんが、インターネット上の多くの偉大な神々が詳細な紹介をしています。
当社のERPのインターフェースの1つに常に問題がありました。つまり、特定の期間中、応答が特に遅いです。クエリがスタックしている限り、基本的には終了しているため、システムをオフにして再度ログインする必要があります。開発者は常にそうであると報告しています完全な処理はなく、ドラッグするだけです。オンラインで見つけたデッドロック検出コードから新しいストアドプロシージャを作成しました。デッドロックコードは、登録時またはクエリ時のストアドプロシージャの割り当てが原因で発生します。機能が制限されているため、ストアドプロシージャを単独で変更することはできません。 。
このインターフェイスには本番の実際のパフォーマンスログインが含まれるため、通常、実際のパフォーマンスを入力して保存する前にデータをクエリし、それを保存します。オンラインの神の最適化の提案を通じて、最初にテーブルの欠落しているインデックスを見つけます。コードは次のとおりです。
-----------返却失失の索引信息
SELECT avg_total_user_cost * avg_user_impact *（user_scans + user_seeks）AS
PotibleImprovement、
last_user_seek、last_user_scan、
[statement] AS [Object]、
'CREATE INDEX [IDX_'
+ replace（ reverse（substring（reverse（statement）、1、charindex（ '['、reverse（statement））-1））、 ']'、 ''）
+ '_'
+ CONVERT（VARCHAR（32）、GS.group_handle）
+ ']' + 'ON'
+ [ステートメント]
+ '（' + ISNULL（equality_columns、 ''）
+ equality_columnsがNOT NULLかつinequality_columnsがNOT NULL NULLの場合のケース
'、'
そうしないと ''
END
+ ISNULL（inequality_columns、 ''）+ '）' + ISNULL（ 'INCLUDE（'
+ included_columns
+ '）'、 ''）AS Create_Index_Syntax
FROM sys.dm_db_missing_index_groups AS G
INNER JOIN sys.dm_db_missing_index_group_stats AS GS ON G.index_。 GS.group_handle
INNER JOIN sys.dm_db_missing_index_details AS D ON G.index_handle = D.index_handle
WHERE [statement] = '[数件库名 ]。] dbo]。[表名]' ------------ -该表就是位于ERP经常卡住的界面
ORDER BY DESC PossibleImprovement
最も可能性の高い値を持つ最初の2つの列をロックし、Create_Index_Syntax列コマンドをコピーして実行します。
create indexコマンドを実行した後、一定の時間を観察すると、クエリ速度が非常に詳細に向上しています。デッドロック時間が経過する前にデッドロック時間が経過している可能性があります。しばらくして、新しく作成したインデックスが効果的に使用されているかどうかを確認します。
---------クエリインデックスの使用
個別のdb_name（database_id）を
N 'データベース名'、 object_name（a.object_id）をN'table name '、
b.name N'index name'、
user_seeks N'number of user index
lookups '、 user_scans N'user index scanとして選択します
Times '、 last_user_seek N' last search time '、
last_user_scan N' last scan time '、
rows N N' number of rows in the table '
from sys.dm_db_index_usage_stats a join
sys.indexes b
on a.index_id = b.index_id
and a。 object_id = b.object_id
join sysindexes c
on c.id = b.object_id
where database_id = db_id（ 'DB name'）---表示するデータベースに
変更し、 object_name（a.object_id）は 'sys％'
やobject_nameとは異なる （a。object_id）= 'テーブル名'
user_seeks、user_scans、object_name（a.object_id）で並べ替え
上記のコードを実行すると、ユーザーインデックスルックアップの数が急速に増加していることがわかりますが、時々デッドロックが生成されることがあります。ストアドプロシージャの挿入ステートメントが原因で発生したと考えられます。これは、開発者のみを反映し、神々が最適化の方法をアドバイスするのを待っています。
