序文
データベースでは、開発ルールがたくさんあります。データベース内のデータベース機能の過度の使用を避けるべきです。過度の使用は、データベースを遅らせるためにつながることができ、加えてデータベースが拡張困難です。過剰なデータベース内のロジック、その後、サブライブラリー、サブテーブルは、より扱いにくいです。もちろん、単純なアプリケーションのために、非常に多くのルールを持ってする必要はありません。次の規則は、規則は高い同時実行環境では、ほとんどです。
すべてのアプリケーションについては、規則案
1）データベースは、大容量のファイル、および画像を保存しません。
一部の人々は、これが唯一のデータベースへの圧力を増加させる、データベースに、ファイル全体を保存したいbase64で写真。一般的に唯一のストレージ・パス、URLは次のようにすることができます。
2）テーブル、フィールド、英語のアルファベットを使用してデータベース。
コードの仕様では、英語の使用、さらにはスペルをお勧めします。中国の使用は非常に遅れています。また、データベースで行う必要があります。中国では、データベースで発生する可能性が予期しない問題が文字化け。
3）サブクエリが道に参加置き換えるようにしてください
パフォーマンスの低下で、サブクエリの結果からです。たとえば、MySQLでは、サブクエリが明らか参加よりも遅くなり、サブクエリが一時テーブルを作成する必要があります。
4）できるだけインデックスを使用してリンクテーブルのクエリに参加
条件のインデックスが大幅にクエリの効率を向上させることができます使用して、あまりにもデータベースクエリのパフォーマンスを消費しましょう。
5）インデックスが使用されていない場合、インデックスの使用は、インデックスが使用できないインデックスを使用することができ
複数のフィールド値は同じのために、インデックスを使用しないでください。これは、あなたの目標を達成するが、データベースへの圧力を増加させませんでした。それが遅くなりますので、あなたはデータとインデックススペースを挿入したとき。
ないインデックスより良い、それがデータベースに過度の圧力につながります。
頻繁にクエリとして使用、及び繰り返し率が高いフィールドではないために、大幅にクエリの効率を向上させる、インデックスを使用してみてください。
6）を避けるデータ型変換の下でのパフォーマンスは、ステルスを引き起こしました
テーブルタイプでは、クエリのタイプと一致しない、クエリのパフォーマンスは、下にも、すべてのクエリをリードします。しかし、クエリのいくつかのタイプのデータベースには、Postgresqlのように、非常に厳しいです。
例えば、ユーザテーブル、データベース内の携帯電話は、文字列型、ユーザからtelphone = 0208653266問合せ選択telphoneの使用であります
ユーザーからの適切な選択telphoneを使用したところtelphone =「0208653266」
7）によって引き起こされる全表スキャンクエリエラー条件を使用しないでください
。NOT ,! =、<> ,! <、！>、NOT IN、LIKE、NOTなど、負のクエリ全表スキャンを引き起こす可能性があります
ファジィクエリB。％開始時に、それは、全表スキャンにつながります
C。データベースを避けてください
8）フィールドの値がヌルであってもよい番号テーブルを避けるために
テーブルのフィールドにはデフォルト値があり、空ではないかもしれません。そうすることで全表スキャンをもたらすことができます。
ここでNUM T = 0から番号を選択します。例えばnumがNULLである場合は、このクエリは、次に、値がnullでないことを保証するために、0 NUMのデフォルト値、テーブルのNUM列に設けられていてもよいTからIDを選択
9）使用時のクエリ号*選択しません
代わりトンから*番号フィールドではなく、選択*特定の照会を使用します。それはデータベースのIO性能を消費しますので、あなたが効果的にカバーインデックスを使用することはできません。
特性の機能または発現を用いて、10）WHERE条件ではありません
日（日）から> = t「の2019年3月15日」からIDを選択全表スキャンを引き起こします。
正しい言葉遣いは次のとおりです。TからSELECT ID WHERE日> =日付（「2019年3月15日午後12時00分○○秒」）
11）単一テーブル30のフィールドの推奨される数よりも小さい場合、データテーブルの単一のインスタンスは、500件の未満の勧告であります
あまりにも多くの分野では、データベーステーブルには、パフォーマンスの低下に制御することが困難と調整することは困難でつながることができます。
12）MySQLの単一のテーブルデータは、理想的には、5000000内に制御します
あまりにも多くのMySQLのテーブル内のデータは、クエリのパフォーマンスの下で動作し、構造を変更することがありますが、このしきい値を500万人と最もよく制御されています。
非常に同時実行アプリケーションのために、規則案
1）テーブル3内に制御可能のインデックス番号、最大でこれ以上5以下です。
インデックスは不可能であり、より多くのインデックスデータベースは、より大きな圧力につながりました。結合指数に使用量。
2）適切参加の使用を避けます
時には、ハンドリングプログラム内のデータベースよりも高速取引に参加。
アプリケーション制御を必要に応じて、3）外部キー、外部キー整合性制約の使用を禁止
外部キーは、テーブルとテーブルの結合の間鉛更新し、関連するテーブル、非常にSQLパフォーマンスへの影響が参加する操作を削除し、さらにはデッドロックが発生します。データベースのパフォーマンスの優先順位を使用して、データベースのパフォーマンスを引き起こす可能性が高い同時実行ビッグデータのビジネスシナリオ高い同時実行。
4）主キー以来、成長を使用しないようにしてください
成長は、主キーではないので、あなたがデータを挿入すると、データベースが最初の最大のインデックス値、およびその後、挿入操作を照会しますので。そのため、短い文字列型の使用または直接GUIDに。
アプリケーション制御を必要に応じて5）外部キー、外部キー整合性制約の使用を避けます
外部キーは、テーブルとテーブルの結合の間鉛更新し、関連するテーブル、非常にSQLパフォーマンスへの影響が参加する操作を削除し、さらにはデッドロックが発生します。データベースのパフォーマンスの優先順位を使用して、データベースのパフォーマンスを引き起こす可能性が高い同時実行ビッグデータのビジネスシナリオ高い同時実行。
6）ストアドプロシージャ、ビュー、トリガ、イベントを使用しないでください
ストアドプロシージャなどを使用して、高い並行性のシナリオでは、データベースは容易CPUが高すぎると崩壊です。優れた拡張制御の目的を達成するために、アプリケーションにCPUの移動端末の推奨摂取を確立します。
フォローアップは、ゆっくりと、他のルールを追加し、問題や提案が発生しました...
いいえ私は誰もが共有するための元の記事の経験の公開、長年に集中することができます。
