MySQL データベース設計の概要

ルール 1: 一般に、トランザクション サポートが必要な場合は、MyISAM ストレージ エンジンを選択できます。InnoDB ストレージ エンジンを使用する必要があります。

注: MyISAM ストレージ エンジンの B ツリー インデックスには大きな制限があります。インデックスに参加するすべてのフィールドの長さの合計が 1000 バイトを超えることはできません。さらに、MyISAM のデータとインデックスは分離されていますが、 InnoDB のデータ ストレージはクラスター インデックスによって順序付けされており、主キーはデフォルトのクラスター インデックスです。したがって、一般に MyISAM の方が InnoDB よりもクエリ パフォーマンスが高くなりますが、InnoDB のクエリ パフォーマンスはプライマリに基づいています。キーが非常に高いです。

ルール 2: 命名ルール。

1. データベース名とテーブル名は、提供されるビジネスモジュールの名前と可能な限り一致している必要があります

2. 同じサブモジュールを提供するテーブルのクラスには、サブモジュール名(または単語の一部) できる限り

3. テーブル名には、保存されたデータに対応する単語が含まれるようにする必要があります

4. フィールド名も実際のデータに対応するように努める必要があります

5. ジョイントインデックス名すべてのインデックス キーのフィールド名または略語、および各フィールド名を含めるようにする必要があります。インデックス名の順序は、インデックス内のインデックス キーのインデックス順序と一致する必要があります。また、それを示すために idx に似たプレフィックスまたはサフィックスを含めるようにしてください。オブジェクトタイプがインデックスであること。

6. 制約などの他のオブジェクトにも、それぞれの関係を示すために、可能な限り、それらが属するテーブルまたは他のオブジェクトの名前を含める必要があります

ルール 3: データベースフィールドの型定義

1. 多くの場合、計算や並べ替えなどが必要になります。CPU フィールドの場合は、TIMESTAMP (4 バイト、最小値 1970-01-01 00:00:00) を使用するなど、より高速なフィールドを選択するようにしてください。 code>Datetime (8 バイト、最小値 1001-01-01 00:00:00)、浮動小数点と文字型を整数に置き換えますTIMESTAMP(4个字节，最小值1970-01-01 00:00:00)代替Datetime（8个字节，最小值1001-01-01 00:00:00）,通过整型替代浮点型和字符型

2. 变长字段使用varchar，不要使用char

3. 可変長フィールドには varchar を使用しますchar は使用しないでください

バイナリ マルチメディア データ、パイプライン データ (ログなど)、および非常に大きなテキスト データの場合は、データベース フィールドに配置しないでください

ルール 4:ビジネス ロジックの実行プロセスは、テーブルに初期値を読み取る必要があります。負の値または無限の値を読み取るときのビジネス障害を回避する

ルール 5: パラダイム理論に従う必要はなく、適度な冗長性を持ち、クエリで結合を最小限に抑えます

ルール 6: 大きなフィールドへのアクセス頻度を下げるデータテーブルに分割されます。一部の大きなフィールドは多くのスペースを占有し、他のフィールドよりもアクセス頻度が大幅に低くなります。この場合、フィールドを分割することで、頻繁なクエリで大きなフィールドを読み取る必要がなくなり、IO リソースが無駄になります。

ルール 7: 大きなテーブルは水平に分割できます。大きなテーブルはクエリの効率に影響します。たとえば、時間に応じて増加するデータを時間に基づいて分割することができます。 IDで分割されたデータは、データベースのID%数に応じて分割できます。

ルール 8: ビジネスに必要な関連インデックスは、実際の設計に従って構築された SQL ステートメントの where 条件に従って決定されます。ビジネスに必要でないインデックスは構築しないでください。結合インデックス (または主キー) フィールドに存在することが許可されます。特に、このフィールドは条件ステートメントにはまったく表示されません。

ルール 9: レコードの 1 つ以上のフィールドを一意に決定するには、主キーまたは一意のインデックスを確立する必要があります。クエリの効率を向上させるために、共通のインデックスを構築します

。 10: ビジネスで使用されるテーブル。一部のレコードには、レコードがほとんどないか、レコードが 1 つしかない場合があります。制約のニーズを満たすには、インデックスを作成するか、主キーを設定する必要があります。

ルール 11: 値を繰り返すことができず、クエリ条件としてよく使用されるフィールドの場合は、一意のインデックスを構築する必要があり (主キーのデフォルトは一意のインデックス)、クエリ内のこのフィールドの条件は条件は最初の位置に配置する必要があります。このフィールドに関連する結合インデックスを作成する必要はありません。

ルール 12: 値が一意ではない頻繁にクエリされるフィールドについては、フィールド条件をクエリ ステートメントの最初の位置に配置することも検討する必要があります。同じ方法が結合インデックスにも使用されます。 。

ルール 13

: 企業が非一意のインデックスを通じてデータにアクセスする場合、原則として、密度が高すぎる場合は、インデックス値を通じて返されるレコード密度を考慮する必要があります。サイズが大きい場合、Indexed を確立するのは適切ではありません。

このインデックスを通じて取得されるデータの量がテーブル内の全データの 20% を超える場合は、インデックスを確立するコストも考慮する必要があります。同時に、インデックス スキャンによってランダムな I/O が生成されるため、そのコストも考慮する必要があります。効率はインデックス全体の効率よりも高く、テーブル順次スキャンの場合の順次 I/O は大幅に低くなります。データベース システムは、クエリを最適化するときにこのインデックスを使用しない場合があります。

ルール 14

: 結合インデックス (または結合主キー) を必要とするデータベースは、インデックスの順序に注意する必要があります。 SQL ステートメント内の一致条件もインデックスの順序と一致している必要があります。 🎜🎜注: インデックス作成が正しくないと、重大な結果が生じる可能性もあります。 🎜

ルール 15: テーブル内の複数のフィールド クエリはクエリ条件として使用され、他のインデックスは含まれず、フィールドの結合値は繰り返されません。これらの複数のフィールドに対して一意の結合インデックスを構築できるとします。インデックス フィールドが (a1, a2 ,...an) の場合、クエリ条件 (a1 op val1,a2 op val2,...am op valm)m の場合、インデックスは次のようになります。が使用され、クエリ条件内のフィールドの位置がインデックス内のフィールドの位置が一致していると同じです。 <code>(a1 op val1,a2 op val2,...am op valm)m,可以用到索引，查询条件中字段的位置与索引中的字段位置是一致的。

规则16：联合索引的建立原则(以下均假设在数据库表的字段a,b,c上建立联合索引(a,b,c))

1. 联合索引中的字段应尽量满足过滤数据从多到少的顺序，也就是说差异最大的字段应该房子第一个字段

2. 建立索引尽量与SQL语句的条件顺序一致，使SQL语句尽量以整个索引为条件，尽量避免以索引的一部分(特别是首个条件与索引的首个字段不一致时)作为查询的条件

3. Where a=1,where a>=12 and a=40为条件可以用到此联合索引；而这些语句where b=10,where c=221,where b>=12 and c=2则无法用到这个联合索引。

ルール 16
4. : ジョイントインデックスを確立するための原則 (以下では、データベーステーブルのフィールド a、b、c にジョイントインデックス (a、b、c) が確立されていることを前提としています)

   
   

ジョイント内のフィールドインデックスを満足するように努める必要があります。 最も大きいものから最も小さいものへの順序でデータをフィルタリングします。つまり、最大の差異を持つフィールドが最初のフィールドになる必要があります
インデックスを作成するときは、条件の順序と一致するようにしてください。 SQL ステートメントは可能な限りインデックス全体に基づくようにし、インデックスの一部 (特に最初の条件がインデックスの最初のフィールドと一致しない場合) がインデックスとして使用されることを避けるようにしてください。クエリ条件

6. 
   
   Where a=1、Where a>=12 および a=40 は次のように使用できます。この結合インデックスを使用するための条件。ただし、where b=10、where c=221、where b>=12 および c=2 のステートメントは、この結合インデックスには使用できません。

クエリが必要なすべてのデータベースフィールドがインデックスに反映されている場合、データベースはテーブル全体をスキャンすることなく、インデックスに直接クエリを実行してクエリ情報を取得できます（これはいわゆるキーです）のみ)、これによりクエリ効率が大幅に向上します。 インデックスは、他のテーブルフィールドと関連付けて a、ab、abc をクエリするときに使用できます。

b、c、bc、ac の代わりに a、ab、abc が順序にある​​場合、および order by または group の場合に使用できます。インデックス

以下の状況では、結合インデックス
1. を使用するよりも、テーブルのスキャンと並べ替えの方が効果的である可能性があります。 テーブルは、すべてのデータの大部分を占めています。クエリ対象のデータ ステーション内。

2. ルール 17

   : 重要なビジネスがデータテーブルにアクセスする場合。ただし、インデックスを介してデータにアクセスできない場合は、連続してアクセスされるレコードの数が 10 を超えないようにする必要があります。

3. ルール 18

   : クエリ ステートメントを合理的に作成する

4. 。

   Insert ステートメントでは、テストによると、1,000 個の項目を挿入する場合に最も効率的ですが、同じ挿入を複数回実行する場合は、分割する必要があります。バッチ化された。クエリステートメントの長さは、mysqld のパラメータ max_allowed_pa​​cket よりも小さくする必要があることに注意してください

5. クエリ条件内のさまざまな論理演算子の実行順序は and、or、in であるため、クエリ内での in の使用は避けるようにしてください。大規模なセットで使用します

6. mysql には、Join メソッドが 1 つしかなく、Nested Join しかなく、mysql の結合がネストされたループを通じて実装されるため、大きなレコード セットを駆動するには常に小さな結果セットを使用してください。大きなレコード セットを駆動する小さな結果セットの原理は、入れ子になったループのループ数を減らし、IO の総量と CPU 操作の数を減らすために使用されます

7. 入れ子結合の内部ループを可能な限り最適化します。

必要な列のみを取得し、select *を使用しないようにしてください

最も効果的なフィルターフィールドのみを使用してください。where 句のフィルター条件を少なくすることをお勧めします

1. 複雑な結合や結合を避けるようにしてくださいサブクエリ

Mysql 同時実行の量が多すぎると、全体のパフォーマンスが大幅に低下します。これは主に MyIsam が使用するテーブル ロックの競合ロック制御に関係します。行ロックが改善されました。

ルール 19

: アプリケーション システムの最適化

🎜🎜🎜 変更が少ない一部のアクティブ データについては、アプリケーション層キャッシュを通じてメモリにキャッシュし、パフォーマンスを桁違いに向上させます。 🎜🎜🎜🎜同じクエリの繰り返し実行をマージして、IO 回数を削減します。最後の C. トランザクションの最小相関の原則 🎜

以上がMySQL データベース設計の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。