13

基本的な最適化手法のリストを取得できますか（モデリングからクエリ、インデックスの作成、ビューからクエリの最適化まで）。これらのリストを、回答ごとに1つのテクニックとして用意しておくと便利です。趣味の人として、これはとても便利だと思います。ありがとう。

また、曖昧すぎないように、MySQLやOracleなどのメインストリームDBを使用しており、DBには最大10個のテーブルに500,000〜1m程度のレコードが含まれ、一部には外部キー制約があり、すべて最も一般的なストレージエンジン（例：InnoDB for MySQL）。そしてもちろん、PKなどの基本はFK制約と同様に定義されています。

4

7 に答える 7

15

インデックスについて学び、それらを適切に使用します。一般的に*、次のガイドラインに従ってください。

  • すべてのテーブルにはクラスター化されたインデックスが必要です
  • フィルタと並べ替えに使用されるフィールドは、インデックス作成に適しています。
  • より選択的なフィールドは、インデックス作成のより良い候補です
  • 重要なクエリで最高のパフォーマンスを得るには、それらのクエリの「カバーインデックス」を設計します
  • インデックスが実際に使用されていることを確認し、使用されていないインデックスを削除します
  • テーブルに15個のフィールドがあり、それぞれが1つのフィールドしかない15個のインデックスを作成する場合、それは間違っています:)

*自分が何をしているのかを知っている場合、これらのルールにはいくつかの例外があります。私の経験はMicrosoftSQLServerですが、このアドバイスのほとんどは別のRDMSにも当てはまると思います。

于 2010-05-11T22:10:59.630 に答える
7

IMO、これまでで最高の最適化は、データモデルをそれが構築された問題のドメインに適合させることです。そうでない場合、結果として生じる症状は、必要な情報を取得するための記述が困難または複雑なクエリであり、通常、データベースに対してレポートを作成するときに発生します。したがって、データベースを設計する際には、ユーザーがシステムに求める情報の種類と性質（レポートなど）を把握しておくと役立ちます。

于 2010-04-25T22:07:05.530 に答える
5

データベース設計について話すときは、データベースの正規化を確認してください。たとえば、ウィキペディアの記事：正規形。

優れた設計があり、それでもパフォーマンスを最適化する必要がある場合は、非正規化を試してください。

リレーショナルモデルで効率的にカバーされていない特定のニーズがある場合は、NoSQLという用語でカバーされている他のモデルを調べてください。

于 2010-04-25T21:22:40.450 に答える
3

いくつかのクエリ/スキーマの最適化：

  • DISTINCTまたはGROUPBYを使用するときは注意してください。多くの新しい開発者は、DISTINCTが実際には必要ない場所、またはExistsステートメントまたは派生クエリを使用してより効率的に書き直すことができる場所でDISTINCTを使用することがわかりました。

  • 左結合に注意してください。多くの場合、新しいSQL開発者は、その場にあるスキーマを無視し、実際には必要のない場所で左結合を使用します。例えば：

Select
From Orders
    Left Join Customers
        On Customers.Id = Orders.CustomerId

Orders.CustomerIdが必須列の場合、左結合を使用する必要はありません。

  • 新機能の学生になりましょう。現在、MySQLは共通テーブル式をサポートしていません。つまり、一部のタイプのクエリは煩雑であり、CTEがサポートされている場合よりも書き込みが遅くなる可能性があります。しかし、それは永遠に真実ではありません。既存のクエリをより効率的にするために使用される可能性のあるMySQLの新しい構文機能についていく。

  • どこでも代理キーを使用する必要はありません。多くの場合、開発者が追加の結合を回避できるようにするインテリジェントキー（たとえば、米国の州の略語、通貨コードなど）により適したテーブルが存在する可能性があります。

  • 可能であれば、OLAPまたはレポートサーバーにデータをアーカイブする方法を見つけてください。本番データを小さくできるほど、実行速度は速くなります。

于 2010-05-15T03:57:02.277 に答える
2

問題を簡潔にモデル化する設計は、常に良いスタートです。データモデルを過度に一般化すると、パフォーマンスの問題が発生する可能性があります。たとえば、RDBMSをばかげた「名前/値」ストアとして使用する超柔軟性を追求するプロジェクトの報告を聞いたことがあります。その結果、パフォーマンスは驚くべきものでした。

優れた設計が整ったら、RDBMSが提供するツールを使用して、優れたパフォーマンスを実現します。単一フィールドPK（コンポジットなし）、ただし、一意の制約を持つインデックスとしてのコンポジットビジネスキー、適切なデータ型の使用。たとえば、charなどではなく数値に適切な数値型を使用します。RDBMSが実行されているハードウェアの物理的属性も考慮する必要があります。これは、クエリ時間の大部分がディスクI / Oであることが多いためですが、もちろんこれを当然のこととは考えないでください。プロファイラーを使用して、時間がどこに向かっているのかを調べてください。 。

更新/クエリの比率によっては、マテリアライズドビュー/インデックス付きビューは、実行速度の遅いクエリのパフォーマンスを向上させるのに役立ちます。貧乏人の代替手段は、トリガーを使用して、実行が遅く、頻繁に変更されないビューの結果をテーブルに取り込むプロシージャを呼び出すことです。

クエリの最適化はデータベースに依存することが多いため、少しブラックアートですが、ここではいくつかの経験則を示します-SQLの最適化。

最後に、質問の意図した範囲外である可能性がありますが、アプリケーションで優れたデータアクセス層を使用し、独自のデータアクセス層を使用する誘惑を避けてください。すべての主要言語で確実にテストされたパフォーマンスの高い実装が利用可能です。データアクセス層、中間層、およびアプリケーション層でキャッシュを使用すると、パフォーマンスを大幅に向上させることができます。

于 2010-05-14T19:51:22.483 に答える
1

可能な限り、使用するクエリを減らしてください。「JOIN」を使用し、テーブルをグループ化して、1つのクエリで結果が得られるようにします。

良い例は、単一のクエリですべてのツリーノードの親を順序付けて取得するためのModified Preorder Tree Transversal（MPTT ）です。

于 2010-05-18T11:52:23.280 に答える
0

最適化に全体的なアプローチを取ります。

低速ディスク、ネットワーク遅延、メモリ不足、およびサーバー負荷の影響を考慮してください。

于 2010-05-18T11:34:29.800 に答える