DBA を虜にする 5 つの SQL ヒント

1. インデックス列に対して Function を呼び出さないでください

そうすることで、データベースがこのインデックスを使用できなくなります。これを行うと、指定されたパーティションからデータが読み取られなくなるため、この問題はパーティション テーブルにも影響を与える可能性があります。ただし、テーブルスペース全体がスキャンされます。データ ボリュームが大きいデータ テーブルの場合、これはパフォーマンスに壊滅的な影響を及ぼします。

これはしないでください:

WHERE
TIME_ID+14 > to_number(to_char(sysdate,'J'))

こうすべき:

WHERE
TIME_ID > to_number(to_char(sysdate-14,'J'))

2. Analyze を使用して複雑な SQL を最適化します

これを行わないと、データベースのクエリ オプティマイザーの使用を拒否して負けることになります。オポチュニティを使用して接続を最適化します。 100 万件のレコードを含む一時テーブルを作成するとします。それが分析されない場合、オプティマイザーは既存の手がかりからテーブルの実際の内容を取得できないため、ネストされたループ結合を使用してスキャンすることしか決定できません。データ テーブルを 1 行ずつ実行します。データ量が多くない場合は、パフォーマンスの低下を感じないかもしれませんが、データ セットが増加すると、データベースのパフォーマンスはますます低下します。

これを行うことをお勧めします:

ANALYZE TABLE <TABLE_NAME> COMPUTE STATISTICS

3. 複雑な SQL をいくつかのステップに分割して実行します

SQL をピザとして考えてください。ピザを丸ごと口に飲み込んで噛むことはないと思います。

複雑な SQL クエリを作成する場合は、SQL が単純であるほど、オプティマイザーの効果が高くなります。また、各データ テーブルのデータのデバッグが容易になります。

IV. Distinct は必要な場合にのみ使用してください

これは、2 つ以上の重複レコードを返す SQL クエリで Distinct を使用することがよくあります。ただし、Distinct を使用する目的は明確でなければなりません。返されるレコードがユーザー ID など、一意であることが確実な場合にのみ使用できます。 Distinct を乱用すると、複数テーブルの結合クエリなどの予期しないエラーが発生します。

5. インデックスを合理的に作成する

最後のポイントは、テーブルのインデックスを合理的に作成することです。簡単に言うと、100,000 件のレコードがあるデータ テーブルがある場合、次のような情報をクエリすることがあります。「私の顧客情報の 1 つはここにあります。」そうですか？」インデックスを使用すると、この顧客情報の取得は非常に高速になります。インデックスを使用しない場合、データベース オプティマイザーはフル テーブル スキャンを選択します。これは、データ量が大きい場合には悪夢です。