[出典] MySQLデータベースの鉄則

-

鉄の法則

レベル

所見

文字集合

UTF-8を使いましょう。 絵文字が保存されている場合は、保存にはutf8mb4を使ってください。

強制的

utf8_general_ci

強制的

-

鉄の法則

レベル

所見

釈義

フィールドアノテーションを必ず用意してください。

強制的

UTF-8を使いましょう。 絵文字が保存されている場合は、保存にはutf8mb4を使ってください。

強制的

名前はis_xxでなければならず、データ型は符号なしのtinyint(1 yes, 0 no)です。例:is_deleted(1 delete, 0 not deleted)。

強制的

負でなければ、任意のフィールドは符号なしでなければなりません

テーブル名、フィールド名

使用可能なのは小文字のアルファベット、アンダースコア、または数字のみです。 下線や数字で始めることは禁止されています。 2つのアンダーラインの間には数字のみが禁止されています。 保留語を無効にすること; テーブル名での複数形名詞の使用は禁止されています。

強制的

データベース名はアプリケーション名と一致し、テーブル名はテーブルのビジネスName_Roleで名付けられるべきです。

強制的

プライマリキーインデックスはフィールド名pk_使います。 フィールド名uk_一意インデックス; 通常のインデックスはidx_フィールド名を使用します。

強制的

pk_が主キーです。 uk_は一意鍵です。 idx_ はインデックスです

十進分類

データ型は10進数であり、floatやdoubleの使用は禁止されており、floatとdoubleは精度が失われます。保存されるデータ範囲が10進数の範囲を超える場合は、整数と10進数に分割して別々に保存することが推奨されます。

強制的

varcharは可変長文字列で、事前にストレージ容量が割り当てられていません。長さは5000文字を超えてはいけません。5000文字を超える場合はテキストを適用します(別のテーブルを作成し、プライマリキーを対応させて他のフィールドのインデックス効率に影響しないようにしてください)。

強制的

id(データ型は符号なしbigint、単一のテーブルインクリメント、ステップサイズは1)、gmt_create、gmt_modified(アクティブ作成時間、パッシブ更新時間、データ型はdatetime)。

強制的

フィールドは適切な冗長性を許容しますが、データの一貫性を考慮し、冗長フィールドは1) 頻度の低い修正を持つべきです。 2) ヴァルチャーの超長フィールドではなく、ましてやテキストフィールドではありません。

おすすめ

パーティショニングは、単一テーブルの行数が500万行を超える場合、または単一テーブルの容量が2GBを超える場合にのみ推奨されます。

おすすめ

-

鉄の法則

レベル

所見

ユニークインデックス

ビジネスにおいて独自の特徴を持つフィールドは、たとえ複数のフィールドの組み合わせであっても、一意にインデックス化されなければなりません。 ユニークなインデックスはインサート速度に影響を与えますが、この損失は無視できる程度であり、クエリ速度を大幅に向上させます。 さらに、アプリケーション層が非常に完全なチェック制御を持っていても、一意インデックスが存在しない限り、マーフィーの法則によれば、必ず汚れたデータが生成されます。

強制的

3つ以上のテーブルでは結合が禁止され、結合が必要なフィールドは禁止され、データ型は一貫していなければなりません。 複数のテーブルにクエリが関連付けられている場合、関連するフィールドにインデックスが必要であることを確認してください。 たとえダブルテーブルジョインがあっても、テーブルのインデックス作成やSQLのパフォーマンスに注意してください。

強制的

インデックス長は指定しなければならず、すべてのフィールドをインデックスする必要はなく、実際のテキストの区別に従ってインデックス長を決定すればよい。 インデックス長と区別は矛盾の一組であり、一般的に文字列タイプデータでは、長さ20のインデックスは90%を超える区別度を持ち、これはカウント(左(列名、インデックス長))/カウント(*)の区別度によって決定されます。

強制的

ページ検索ではぼかしや完全なぼかしを禁止しています。必要なら検索エンジンで解決してください。 禁止理由:インデックスファイルはBツリーの最左端のプレフィックスマッチング特性を持ち、左側の値が決定されていなければ、このインデックスは使用できません。

強制的

シナリオごとに順序があるなら、指数の秩序性に注意してください。 順序の最後のフィールドは結合インデックスの一部であり、file_sortを防ぎクエリ性能に影響を与えるためにインデックスの組み合わせ順序の末尾に配置されます。 例:a=はどこですか? そして b=? 順番はc; 指数はa_b_cとして構築されるべきです。 反例として、インデックスにレンジルックアップがある場合、インデックスの順序性は利用できません。例えば、a>10はbによる順序です。 インデックスa_bはソートできません。

おすすめ