delete from a A where a.ID = 132.
テーブル A には約 5000 のレコードが含まれており、A.ID はテーブル A の主キーです。しかし、削除に時間がかかっています。タイムアウトになることもあります。そのテーブルには 3 つのインデックスが含まれており、3 つの外部キーによって参照されます。主キーに基づいて削除しているのに、なぜ時間がかかるのか説明してもらえますか。そして、この問題を最適化する方法を教えてください...?
1466 次
5 に答える
12
考えられる原因：
1) カスケード削除操作
2) トリガー
3）主キー列の型が整数以外であるため、比較を行うために各 pk 値の型変換が強制されます。これには、完全なテーブル スキャンが必要です。
4）質問に投稿したように、クエリは本当にドットで終わりますか？その場合、その数値は整数ではなく浮動小数点数であると見なされる可能性があり、3) と同様の型変換が発生します。
5）削除クエリは、他の遅いクエリがロックを解放するのを待っています
于 2009-10-27T12:44:21.993 に答える
3
明らかに、長い時間がかかるべきではありません。ただし、その理由を正確に把握するには、ここには十分な情報がありません。ただし、外部キーに注目する必要があると言えます。
これらは、他のはるかに大きなテーブルからの制約を課すと、処理が遅くなる可能性があります。また、タイムアウトが削除を妨げる整合性チェックが原因であることがわかる場合もあります (問題は、タイムアウトではなく例外が発生しない理由です)。
私の次のステップは、外部キーを削除してパフォーマンスをチェックすることです。次に、一度に 1 つずつ元に戻して、パフォーマンスを確認します。
他の操作 (挿入、選択、更新など) に時間がかかっていませんか?
于 2009-10-27T12:44:01.587 に答える
1
最初の考え: 外部キーのインデックス?
- これは、前述のカスケード削除に関連しています
- すべての子テーブルの muts がチェックされ、合計 500,000 の子行がある場合、これにはもちろん時間がかかる場合があります...
再考: 発火のトリガー？
- このテーブルまたは子テーブルで、またはコードなどを介してカスケードしようとしています
- 神は禁じます、削除された各行のカーソル...
于 2009-10-27T12:50:19.453 に答える
1
統計を更新してみてください。5000行は大したことではありません。これを定期的に行っている場合は、そのテーブルのメンテナンスもスケジュールする必要があります (つまり、インデックスの再構築、統計の更新など)。
于 2009-10-27T13:09:52.830 に答える
0
他の人が観察したように、考えられる容疑者は外部キーです。
第一に、従属テーブルが他のテーブルによって参照される場合、ON DELETE CASCADE が勢いを増す可能性があるためです。
第 2 に、削除する必要がある行を他のユーザーがロックしている可能性があるためです。これがタイムアウトの最も可能性の高い原因です。これがどのように機能するかは、データベースのフレーバーとバージョンによって異なります。たとえば、古いバージョンの Oracle (<=8.0) では、外部キー列がインデックス化されていない限り、従属テーブル全体をロックする必要がありました。
于 2009-10-27T13:07:36.903 に答える