MySQL 30軍事ルールの詳細な説明

1. 基本仕様

（1）InnoDBストレージエンジンを使用する必要があります。解釈：トランザクション、行レベルのロック、より優れた同時実行性、CPUおよびメモリキャッシュページの最適化をサポートし、より高いリソース使用率を実現します。

（２）解釈にはUTF8文字セットを使用する必要があります：Unicode、トランスコードの必要がなく、文字化けのリスクがなく、スペースを節約できます。

（３）データテーブルとデータフィールドには中国語で注釈を付ける必要があります。N年後、r1、r2、r3フィールドが何のために使用されるのか誰が知っているでしょうか？

（4）ストアドプロシージャ、ビュー、トリガー、イベントの使用を禁止する
解釈: 同時実行性の高いビッグデータ インターネット ビジネスの場合、アーキテクチャ設計の考え方は、「データベース CPU を解放し、コンピューティングをサービス レイヤーに移す」ことです。同時実行性が大きい場合、これらの機能によってデータベースの速度が低下する可能性があります。ビジネス ロジックをサービス レイヤーに配置すると、スケーラビリティが向上し、「マシンを追加してパフォーマンスを向上させる」ことが簡単に実現できます。データベースはストレージとインデックス作成に優れているため、CPUコンピューティングを上位に引き上げるべきである。

（５）大きなファイルや大きな写真を保存しない 解釈：データベースが得意ではないことをなぜ許すのでしょうか？大きなファイルや写真はファイルシステムに保存されるため、URIはデータベースに保存する方がよい

2. 命名基準

（6）データベースに接続できるのはIPアドレスではなく、イントラネットドメイン名のみです。

（７）オンライン環境、開発環境、テスト環境データベースイントラネットのドメイン名は、商号：xxxの命名規則に従う。
オンライン環境: dj.xxx.db
開発環境: dj.xxx.rdb
テスト環境: dj.xxx.tdb
スレーブ データベースの名前の後に -s が追加され、スタンバイ データベースの名前の後に -ss が追加されます。オンライン スレーブ データベース: dj.xxx-s.db
オンライン バックアップ データベース: dj.xxx-sss.db

（8）データベース名、テーブル名、フィールド名：小文字、下線付き、32文字以内、説明が明確でなければならない、ピンインと英語の組み合わせは禁止

（９）テーブル名t_xxx、非ユニークインデックス名idx_xxx、ユニークインデックス名uniq_xxx

3. テーブル設計仕様

（10）単一インスタンステーブルの数は500未満でなければならない

（11）1つのテーブル内の列数は30未満でなければならない

（12）テーブルには主キーが必要です。たとえば、自動インクリメント主キーの解釈は次のとおりです。
a) 主キーの増分とデータ行の書き込みにより、挿入パフォーマンスが向上し、ページ分割が回避され、テーブルの断片化が軽減され、スペースとメモリの使用が改善されます。
b) 主キーのデータ型は短くする必要があります。Innodb エンジンの通常のインデックスには主キーの値が格納されます。データ型を短くすると、インデックスのディスク領域を効果的に削減し、インデックスのキャッシュ効率を向上させることができます。
c) 主キーのないテーブルを削除すると、行モードのマスタースレーブアーキテクチャでスタンバイデータベースがブロックされます。

（13）外部キーは禁止されています。外部キー整合性制約がある場合、アプリケーション制御が必要です。外部キーはテーブル間の結合を引き起こします。更新および削除操作は関連するテーブルに関係するため、SQLパフォーマンスに大きな影響を与え、デッドロックを引き起こす可能性もあります。同時実行性が高いと、データベースのパフォーマンスに問題が生じやすくなります。ビッグ データと同時実行性が高いビジネス シナリオでは、データベースのパフォーマンスが最優先事項です。

4. フィールド設計仕様

（14）フィールドはNOT NULLとして定義され、デフォルト値が提供されなければならない。
a) NULL列はインデックス/インデックス統計/値の比較をより複雑にし、MySQLの最適化をより困難にします。
b) Null このタイプのデータは、MySQL で特別に処理する必要があり、データベース レコード処理の複雑さが増します。同じ条件下で、テーブルに空のフィールドが多数ある場合、データベース処理のパフォーマンスが大幅に低下します。
c) NULL値はより多くの記憶領域を必要とします。テーブルまたはインデックスの各行のNULL列は、識別するために追加の領域を必要とします。
d) null を扱う場合、is null または is not null のみが使用でき、=、in、<、<>、!=、not in などの演算記号は使用できません。たとえば、name!='shenjian' の場合、name に null 値を持つレコードがあると、クエリ結果には name に null 値を持つレコードは含まれません。

(15) TEXT型とBLOB型の使用を禁止します。解釈: これにより、ディスクとメモリ領域がさらに浪費されます。不必要な大規模フィールドクエリによりホットデータが排除され、メモリヒット率が急激に低下し、データベースのパフォーマンスに影響します。

（16）通貨を保管する際には小数点を使用しないでください。解釈：整数を使用してください。小数点を使用すると、金額が一致しなくなる可能性があります。

（17）携帯電話番号を保存するにはvarchar(20)を使用する必要があります。解釈：
a) 市外局番や国番号の場合、+-()が表示されることがあります。
b) 携帯電話番号で数学演算を実行できますか?
c) VARCHAR はあいまいクエリをサポートできます。例: "138%"

（18）ENUMは禁止されています。代わりにTINYINTを使用できます。
a) 新しいENUM値を追加するにはDDL操作が必要です
b) ENUM の実際の内部ストレージは整数です。文字列を定義したと思いましたか?

5. インデックス設計仕様

（19）1つのテーブル内のインデックスの数は5未満に制限することをお勧めします。

（20）1つのインデックス内のフィールド数は5を超えることはできません。解釈：フィールドが5つを超えると、データを効果的にフィルタリングできなくなります。

（21）頻繁に更新され、差別化の度合いが低い属性に対してインデックス解釈を作成することは禁止されている。
a) 更新によりB+ツリーが変更され、頻繁に更新されるフィールドのインデックス作成によりデータベースのパフォーマンスが大幅に低下します。
b) 「性別」のようにあまり差別化されていない属性の場合、インデックスを作成しても意味がありません。これではデータを効果的にフィルタリングできず、パフォーマンスは完全なテーブルスキャンと同様になります。

（22）複合インデックスを作成する場合、識別力の高いフィールドを先頭に配置する必要があります。解釈：これにより、データをより効果的にフィルタリングできます。

6. SQL使用仕様

(23) SELECT *は使用しないでください。必要なフィールドのみが取得されます。列属性を表示する必要があります。
a) 不要な列を読み取ると、CPU、IO、およびNETの消費量が増加する
b) カバーインデックスを効果的に使用できない
c) SELECT *を使用すると、フィールドを追加または削除した後にプログラムバグが発生しやすくなります。

(24) INSERT INTO t_xxx VALUES(xxx)の使用は禁止されています。指定された挿入列の属性を表示する必要があります。解釈: フィールドを追加または削除すると、プログラムバグが発生しやすくなります。

(25) 暗黙的な属性変換は禁止されています。解釈: SELECT uid FROM t_user WHERE phone=13812345678 は完全なテーブルスキャンとなり、phone インデックスにはヒットしません。なぜだと思いますか? (このオンラインの問題は複数回発生しています)

(26) WHERE条件の属性に関数や式を使用することは禁止されています。解釈: SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15'は完全なテーブルスキャンになります。正しい書き方は次のとおりです: SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')

（27）%で始まる否定クエリとあいまいクエリは禁止されています。
a) 否定的なクエリ条件: NOT、!=、<>、!<、!>、NOT IN、NOT LIKE などの場合、テーブル全体がスキャンされます。
b) %で始まるファジークエリは完全なテーブルスキャンになります

（28）大きなテーブルに対するJOINクエリとサブクエリの解釈は禁止されています。一時テーブルが生成され、メモリとCPUを多く消費し、データベースのパフォーマンスに大きな影響を与えます。

(29) OR条件は禁止されており、INクエリに変更する必要があります。解釈：古いバージョンのMySQLのORクエリはインデックスにヒットできません。インデックスにヒットできたとしても、クエリの最適化を実装するためにデータベースがCPUを多く消費するのはなぜでしょうか？

（30）アプリケーションはSQL例外を捕捉し、それに応じて処理する必要がある

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。