効率的で洗練された SQL の作成方法を説明する記事

select * from を避け、必須フィールドのみを返すようにしてください。

日常的にテーブルデータをクエリする場合、無意識に select * from と書いてすべてのフィールド情報をクエリすることがよくありますが、レコードが少ない単一テーブルでは面白くありませんが、複数のテーブルが関連付けられており、テーブルサイズが大きい場合には select * from が返されます。 all テーブルのフィールドはクエリの効率に影響します。より良い方法は、必要なものをチェックし、必要なフィールド情報のみを返すことです。これは、開発における最も知られていない原則にも一致しており、不必要な情報を公開しないように努めます。

完全なクエリを避け、クエリの粒度をできるだけ小さく制御する

日常的な開発環境のクエリでは、何気なく select * from tableA と記述することがあります。そのようなクエリは、すべてのレコードとすべてのフィールドを返します。そのようなクエリが誤って運用環境にアップグレードされた場合、クエリが遅すぎると悲惨な結果が生じる可能性があります。フルテーブルスキャンは非効率的なクエリ方法であるため、できるだけ避ける必要があります。インデックス、適切なフィルタリング条件、および JOIN 最適化を使用して、テーブル全体のスキャンを削減します。したがって、クエリを実行するときは、できるだけ小さいデータを返すように、where 条件フィルタリング (ページング、フィールドフィルタリング、日付範囲など) を習慣的に追加すると、クエリの効率が大幅に向上します。

クエリを実行するときは、インデックスを使用するようにしてください。事前にインデックスを設計することをお勧めします。

1 つのテーブルにレコードが多すぎる場合、およびインデックス以外のフィールドを介してテーブル関連付けクエリが実行される場合、クエリ効率は非常に低くなります。このとき、関連フィールドにインデックスを付けるとクエリ効率が大幅に向上します。したがって、テーブルを設計するときは、ビジネスシナリオを考慮し、クエリのフィルター処理やテーブルの関連付けによく使用されるフィールドにインデックスを確立することが最善です。これは、後続のクエリに大きなメリットをもたらします。同時に、クエリプロセス中に、インデックス以外のクエリよりもはるかに効率的なインデックスクエリを使用するようにしてください。

インデックス障害のシナリオを回避するように努めてください

インデックスは優れていても、使い方を誤ると期待した効果が得られない場合があるため、インデックスの失敗に着目し、それを回避する必要があります。

インデックス障害の主なシナリオは次のとおりです。

ジョイントインデックスが左端の一致原則を満たしていません
select * クエリを使用する
式操作にインデックス付き列を使用する
インデックス列は組み込み関数を使用します
like ファジークエリの間違った使用
インデックス列は暗黙的な型変換を実行します
使用または操作
インデックス列の比較には >、<、!= などを使用します。
用途がnullではありません
not in および not exixt を使用する
ソートによる間違った順序

更新する場合は完全な変更を避け、必要なフィールドのみを変更します。

テーブルレコードを変更するとき、いくつかの簡単な操作はupdateById(Entity entity)です。更新は成功する可能性がありますが、SQL に注目すると、 Entityのすべてのフィールドが更新されていることがわかり、ステータスを変更するだけでよい場合があります。分野。少数のフィールドのみを変更する後者の効率は、完全な変更よりも明らかに高く、さらに重要なことに、他のフィールドが誤って変更されて他の問題が発生することを防ぐことができます。

文字列型の代わりに数値を使用してみてください

記憶域スペースの節約: 一般に、数値は文字列型よりも占有する記憶域スペースが少なくなります。大規模なデータセットでは、数値型を使用するとデータベースのストレージ要件が大幅に軽減され、システムのパフォーマンスと効率が向上します。
クエリのパフォーマンスの向上: データベースにクエリを実行する場合、通常は文字列型を比較するよりも数値型を比較する方が高速です。数値型は直接比較できるため、文字列型は文字ごとに比較する必要があります。

重要なデータの「完全削除」は慎重に選択してください

データを削除するのは楽しいことですが、特に重要なデータを誤って削除してしまった場合には、危険を伴うこともあります。データの削除には通常、物理的な削除（ハード削除）と論理的な削除が含まれます。ただし、どのような削除であっても、データをすべて削除しない、逃げ出す必要はないという制限条件に注意する必要があります。

物理的な削除により、テーブル内に有効なデータのみが存在し、可読性が良好になると同時に、メモリ領域を節約できます。ただし、物理的に削除した場合、データは復元できない可能性が高くなります。論理削除は安全ではありますが、テーブルデータをある程度汚染するため、後続の関連クエリごとに有効なデータを必ずフィルタリングする必要があります。

一部の貴重な履歴データについては、削除された履歴データを転送するための履歴テーブルの設計を検討できますか? これにより、トレーサビリティを確保できる一方で、元のテーブルデータのシンプルさと有効性も確保できます。。