SQL Serverデータベースに外部キーを持つ約16の他のテーブルによって参照されるテーブル（T1など）があります。データは、LINQToSQLを使用するASP.NETアプリケーションを介してアクセスされます。ユーザーがT1からレコードを削除しようとすると、ステートメントはタイムアウトになります。そのため、最初にT1を参照するテーブルからレコードを削除し、その後にT1のレコードを削除することにしました。問題は、T1からの削除が期待どおりに速く動作しないことです。SQL削除が長すぎます
私の質問は、レコード自体に子レコードがなくても、他の多くのテーブルによって参照されるテーブルからの削除が時間がかかることは普通ですか？
編集：明らかに、タイムアウトの原因は削除自体ではなく、同じDataContextからデータを取得した別のクエリです。あなたの提案をありがとう、私はそれが私たちのスクリプトの実行計画を改善したため、すべての外部キーのインデックスを追加するための提案に答えてマークしました。
私は、あなたの子テーブルのインデックスを調べる必要があるかもしれないと思われます。
FKsがカスケード削除に設定されているかのように聞こえるので、インデックスの最初に親のキーを含むインデックスがテーブルの一部にないと思われます。
このようにして、あなたの削除は子テーブルを完全にスキャンすることになります。子レコードを削除したとしても、それでもまだカスケードセットが残っているのでチェックします。
あなたはそうです、それはすべての子テーブルをスキャンします...私は実行プランをチェックして、テーブルに子レコードがあるかどうかを確認した後、各テーブルに対してdeleteステートメントを実行します。カスケードをアクションなしで置き換えると実行時間が大幅に短縮されると思いますか？ –
あなたはまだやり方で削除を行うことはありません。削除の実行計画を見て、彼らが探している指標を見て、あなたのインデックスをチェックしてください。 –
DBでリレーションシップを定義するときに、Delete ruleをSQLサーバーにCascadeと設定できます。このようにして、親テーブルからレコードを削除すると、レコードは自動的に子テーブルから削除されます。
下の画像を参照してください。
それは長い時間がかかった場合は、削除のプロセスダウン が遅くなり、他の制約を設定している場合があります。
質問から、彼らはすでにこのセットを持っているように聞こえます。 –
linq-to-SQLを使用してリレーションを適切に設定した場合、変更をサブミットすると、子レコードを削除する必要があります。 –
問題は、テーブルがすでにカスケードを使用していることです。なぜなら、削除に時間がかかりすぎる理由の1つであると思います。カスケード機構によって削除される必要がないように、すべての「子」を最初に削除しました。明らかに、これはそんなに良い解決策ではありませんでした：D –
レコードセットで直接操作している場合、Linqは一括削除を行いません。代わりにのレコードを1つずつ削除するのがおそらくです。
パフォーマンスを向上させるには、一括挿入、更新、または削除操作の代わりにストアドプロシージャを使用します。
deleteステートメントでクエリアナライザを実行する必要があります。 SQL Serverのほとんどの実装には、実行計画が表示されるプロファイラが含まれています。速度が「通常」であるかどうかを推測するのではなく、ボトルネックを直接的に特定できます。 –
これらの呼び出し中に何が起きているかを見るためにSQLプロファイラを実行しようとしましたか？ SQLを取得してから実行計画を実行し、遅延がどこにあるかを確認することができます。 –
外部キーにインデックスがありますか？この古い栗を参照してください：http://zootfroot.blogspot.com/2006/01/slow-sql-server-delete.html –