データベースのキャッチ-30

#Database Catch-30

1. 基本仕様

(1) InnoDB ストレージ エンジンを使用する必要があります

解釈: トランザクション、行レベルのロック、同時実行パフォーマンスの向上、CPU およびメモリ キャッシュ ページの最適化をサポートし、結果としてリソース使用率が向上します

(2) UTF8 文字セットを使用する必要があります

解釈: Unicode、トランスコードの必要がなく、文字化けのリスクがなく、スペースを節約できます

(3) データ テーブルとデータ フィールドに中国語のコメントを追加する必要があります

解釈: r1、r2、r3 フィールドが何に使用されるかを N 年後に誰が知ることになるでしょう

##(4) ストアド プロシージャ、ビュー、トリガー、およびイベントの使用は禁止されています

解釈: 高い同時実行性 データ インターネット ビジネスのアーキテクチャ設計のアイデアは「データベース CPU を解放し、計算をサービス層に転送する」 です。同時実行量が大きい場合、これらの機能は非常に重要です。データベースをドラッグして消滅させ、ビジネス ロジックをサービス層に配置してスケーラビリティを向上させることができ、

(5) 大きなファイルや大きな写真を保存することは禁止されています

解釈: なぜデータベースにそのままのことをさせるのか苦手ですか？大きなファイルや写真はファイル システムに保存されますが、URI をデータベースに保存するのはどの程度良いでしょうか?

2. 命名仕様

(6) イントラネット ドメインのみIP ではなく、名前が許可されます。 データベースへの接続

(7) オンライン環境、開発環境、テスト環境 データベースのイントラネット ドメイン名は、命名規則に従います。

# 会社名: xxx

##● オンライン環境：dj .xxx.db

#● 開発環境： dj.xxx.rdb

#● テスト環境： dj.xxx.tdb

● スレーブ ライブラリ名の後に -s ロゴを追加し、スタンバイ データベース名の後に -ss マークを追加します。

#● オンライン スレーブ データベース: dj.xxx-s.db

● オンラインスタンバイデータベース：dj.xxx-sss.db

(8) ライブラリ名、テーブル名、フィールド名：小文字、下線スタイル、32 文字以内、名前は明確に理解できる必要があり、混合使用ピンインと英語の使用は禁止です

(9) テーブル名 t_xxx、非一意インデックス名 idx_xxx、一意インデックス名 uniq_xxx

3. テーブル設計仕様

(10) 単一インスタンス テーブルの数は 500

( 11) 単一テーブルの列数は 30 (12) 未満である必要があります。テーブルには、自動インクリメント主キーなどの主キーが必要です。

解釈:

* a) 主キーがインクリメントされ、データ行が書き込まれます。挿入により、挿入パフォーマンスが向上します。 「ページ」分割、テーブルの断片化を減らし、スペースとメモリの使用量を改善します

* b) 主キーに短いデータ型を選択します。Innodb エンジンの通常のインデックスは主キーの値を保存します。短いデータ型インデックスのディスク領域を効果的に削減し、インデックスのキャッシュ効率を向上させることができます。

* c) 行モードのマスター/スレーブ アーキテクチャで主キーのないテーブルを削除すると、スタンバイ データベースがブロックされます

(13) 外部キーの使用は禁止されています。外部キーの整合性制約がある場合は、アプリケーション制御が必要です。

解釈: Foreignキーによりテーブルが結合され、更新および削除操作には関連するテーブルが関与するため、SQL のパフォーマンスに大きな影響を及ぼし、さらにはデッドロックを引き起こす可能性があります。同時実行性が高いと、データベースのパフォーマンスが容易に低下する可能性があります。 ビッグ データの同時実行性が高いビジネス シナリオでは、データベースの使用はパフォーマンスを優先する必要があります

4. フィールド設計仕様

(14) フィールドは NOT NULL として定義され、デフォルト値が提供される必要があります。

解釈:* a) Null 列によりインデックス/インデックスが有効になります。統計/値の比較はより複雑で、MySQL 向けに最適化するのがより困難です。

* b) このタイプの null には MySQL 内部で特別な処理が必要であり、データベース処理レコードの複雑さが増大します。同じ条件下では、テーブルにはさらに多くの null フィールドが存在します。 複数の null フィールドがある場合、データベースの処理パフォーマンスは大幅に低下します。

* c) null 値にはより多くの記憶領域が必要であり、テーブルの各行に null 列が必要です。テーブルまたはインデックスには追加のスペースが必要です 識別

* d) null を処理するときは、「is null」または「is not null」のみを使用できますが、「=、in、<、<>」は使用できません。 、!=、これらの演算記号には含まれません。例: where name!='shenjian'、name に null 値を持つレコードがある場合、クエリ結果には name に null 値を持つレコードは含まれません

(15) TEXT 型と BLOB 型を使用してください

解釈: より多くのディスクとメモリ領域が浪費され、多数の不必要な大規模フィールド クエリによってホット データが排除され、その結果メモリ ヒット率が急激に低下し、データベースのパフォーマンスに影響を及ぼします

(16) 小数の使用を禁止する通貨を保存する

解釈: 整数を使用します。小数は金額の不一致を引き起こしやすいです

(17) varchar(20) を使用する必要があります。携帯電話番号を保存する

解釈:

* a) 市外局番または国番号に関しては、` -()`

* が表示される場合があります。携帯電話番号は数学的な演算を行いますか?

* c) varchar はファジー クエリをサポートできます。例: `like "138%"`

(18) ENUM の使用は禁止されており、代わりに TINYINT を使用できます

解釈:

* a) 新しい ENUM 値を追加するには DDL 操作が必要です

* b) ENUM の実際の内部ストレージは整数です。文字列を定義していると思いますか?

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

(19) 単一テーブルのインデックス数は 5

(20) 単一インデックスの数以内に制御することを推奨します。フィールドは 5 つを超えることはできません

解釈: フィールドが 5 つを超えると、データのフィルタリングに効果がなくなります

(21) 次の属性にインデックスを作成することは禁止されています。非常に頻繁に更新され、差別化が低い

解釈:

#* a) 更新により B ツリーが変更され、頻繁に更新されるフィールドのインデックス作成によりデータベースのパフォーマンスが大幅に低下します

* b ) 「性別」の区別はありません。大きな属性の場合、インデックスを作成しても意味がありません。データを効果的にフィルタリングできません。パフォーマンスはテーブル全体のスキャンと同様です。

(22) ビルド時結合インデックスの場合は、区別性の高いフィールドを前に置く必要があります

解釈: データをより効果的にフィルタリングできます

#6. SQL 使用法の仕様

# (23) SELECT * の使用は禁止、必要なフィールドのみ取得、指示の表示が必要 カラム属性

解釈:

* a) 不要なカラムを読み込むと、CPU、IO、CPU が増加します。 NET の消費

##* b) カバーインデックスを効果的に利用できない

* c) フィールドの追加または削除後に「SELECT *」を使用すると、プログラムのバグが発生しやすくなります

(24) INSERT INTO t_xxx VALUES(xxx) の使用は禁止されており、指定された挿入列属性を表示する必要があります

解釈: フィールドの追加または削除後にプログラムのバグが発生する可能性があります

(25)属性の暗黙的な変換の使用は禁止されています

解釈: `SELECT uid FROM t_user WHERE Telephone=13812345678` はい これにより、テーブル全体のスキャンが行われますが、電話インデックスにヒットできません。なぜだと思いますか? (このオンライン質問は複数回表示されています)

(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 例外をキャプチャし、それに応じて処理する必要があります。

要約: 大量のデータと高い同時実行性を扱うインターネット ビジネスでは、データベースのパフォーマンスに大きな影響を与えるものを使用することはできません。これを使って。

推奨学習:

MySQL チュートリアル

以上がデータベースのキャッチ-30の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。