MySQL の設計仕様と原則

MYSQL データベース設計仕様

1. データベース命名仕様

26 個の英字を使用します (サイズに依存します)。書かれている）と 0 ～ 9 の自然数（多くの場合は必要ありません）とアンダースコア '_';

名前は簡潔かつ明確である必要があります (長さは 30 文字を超えることはできません);

例: user、stat 、log。 wifi_user、wifi_stat、wifi_log というプレフィックスをデータベースに追加することもできます。

バックアップ データベースでない場合は、0 ～ 9 の自然数を追加できます: user_db_20151210 ;

2. データベーステーブル名 命名規則

は、26 文字の英字 (大文字と小文字を区別) と 0 ～ 9 の自然数 (多くの場合は不要) とプラスで構成されます。アンダースコア「_」;

名前は簡潔かつ明確です。複数の単語はアンダースコア「_」で区切られます;

例: user_login、user_profile、user_detail、user_role、user_role_relation、

user_role_right、user_role_right_relation

テーブル接頭辞「user_」は有効です 同じ関係を持つテーブルをまとめて表示します;

3. データベース テーブル フィールド名の命名規則

は 26 個の英字 (大文字と小文字を区別) と 0 ～ 9 を使用します。これは自然数 (多くの場合は必要ありません) とアンダースコア '_' で構成されます。

名前は簡潔かつ明確であり、複数の単語はアンダースコア「_」で区切られます;

例: user_login テーブルのフィールド user_id、user_name、pass_word、eamil、tickit、status、mobile、add_time;

各テーブルには、自動インクリメント主キー、add_time (デフォルトのシステム時間)

テーブル間で関連付けられたフィールド名は、できるだけ同一である必要があります;

4. データベース テーブルのフィールド タイプの仕様

データを 1 つのフィールドに保存するために使用する記憶域スペースはできるだけ少なくしてください。

例: int を使用できる場合は、varchar、char を使用しないでください。varchar を使用できる場合は、varchar を使用しないでください。 (16)、varchar(256) は使用しないでください;

IP アドレスには int 型を使用するのが最善です;

固定長型には char を使用するのが最善です。次に例を示します。郵便番号;

tinyint を使用できる場合は、smallint、int は使用しないでください。

各フィールドにデフォルト値を与えることが最善であり、null にしないことが最善です;

5. データベース テーブル インデックスの仕様

名前は簡潔かつ明確です。例: user_login テーブルの user_name フィールドのインデックスは、user_name_index の一意のインデックスである必要があります。

はそれぞれの一意のインデックスです。テーブルの主キー インデックスを作成します。

各テーブルに適切なインデックスを作成します。

複合インデックスを確立するときは注意してください。

6. データベース パラダイムを理解するだけです

第一正規形 (1NF): フィールド値はアトミックであり、分割できません (すべてのリレーショナル データベース システムは次の条件を満たします)第一正規形);

例: 名前フィールド、姓と名は全体です。姓と名を区別したい場合は、2 つの独立したフィールドを設定する必要があります。

第 2 正規形 (2NF): テーブルには主キーが必要です。つまり、データの各行を一意に区別できます。

備考: 最初に第 1 正規形が満たされる必要があります。

第 3 正規形 (3NF): テーブルには、他の関連テーブルの非キー フィールドに関する情報を含めることはできません。つまり、データ テーブルに冗長なフィールドを含めることはできません。;

備考: 2 番目正規形は最初に満たされる必要があります;

データベースの 3 番目の正規形:

①フィールドは分離できません。

②主キーがあり、主キー以外のフィールドは主キーに依存します。

③主キー以外のフィールドは相互に依存できません。

#MYSQL データベース設計原則

#1. 基本原則

#MYSQL データベース設計原則では操作を実行しないでください。データベース;

CPU 計算をビジネス レイヤーに移動する必要があります;

列数を制御します (フィールド数は少なく正確です。フィールド数は 20 以内にすることをお勧めします) ;

パラダイムと冗長性のバランスを取る (効率を優先し、しばしばパラダイムを犠牲にする)

3B を拒否する (大きな SQL ステートメントを拒否する: 大きな SQL、大きなものを拒否する: 大きなトランザクション、大きなバッチを拒否する: 大きなバッチ) ;

2、フィールド クラスの原則

数値型を適切に使用します (スペースを節約するために適切なフィールド型を使用します);

文字は数値に変換されます (最適な変換が可能になり、スペースも節約され、クエリのパフォーマンスも向上します) ;

NULL フィールドの使用は避けてください (NULL フィールドはクエリと最適化が難しく、NULL フィールドのインデックスには余分なスペースが必要で、NULL の複合インデックスは必要です)フィールドは無効です);

テキスト タイプの使用頻度を下げます (テキスト フィールドの代わりに varchar を使用するようにしてください);

3. インデックスの原則

インデックスを使用する合理的に (クエリを改善し、更新を遅くするには、インデックスが多いほど良いです);

文字フィールドはプレフィックス インデックスを構築する必要があります;

インデックスに対して列操作を実行しないでください;

Innodb の主キーは自動インクリメント列の使用を推奨します (主キーはクラスター化インデックスを作成します。主キーは変更しないでください。文字列を主キーにするべきではありません) (Innodb のインデックス ストレージ構造を理解していればわかるでしょう) ;

外部キーは使用されません (プログラムによって保証されています);

4. SQL クラスの原則

SQL ステートメントは可能な限り単純です(1 つの SQL は 1 つの CPU でのみ操作でき、大きなステートメントはロック時間を短縮するために小さなステートメントに分割され、1 つの大きな SQL はライブラリ全体をブロックする可能性があります。);

単純なトランザクション ;

回避するtrig/func を使用します (トリガーと関数はクライアント プログラムによって置き換えられません);

select * は使用しないでください (CPU、IO、メモリ、帯域幅を消費するため、この種のプログラムはスケーラブルではありません);

OR は IN として書き換えられます (or の効率は n レベルです);

OR は UNION として書き換えられます (mysql インデックスのマージは非常に遅れます);

select id from t where phone = ’159′ or name = ‘john’;

=>

select id from t where phone=’159′
union
select id from t where name=’jonh’

負の % は避けてください;

count(*) は注意して使用してください;

効率的なページングを制限してください (制限が大きいほど効率は低くなります);

Union ではなく Union all (union には重複排除のオーバーヘッドがあります);

結合の使用を減らします;

グループ化を使用します;

同じ型の比較を使用してください;

バッチバッチ更新;

5. パフォーマンス分析ツール

show profile;

mysqlsla;

mysqldumpslow;

説明;

遅いログを表示;

プロセスリストを表示;

推奨チュートリアル: 「MySQL チュートリアル 」

以上がMySQL の設計仕様と原則の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。