目次
データベース設計に不可欠な知識これは将来の進歩の基礎です
1.データベースコマンドの仕様
第二に、データベースの基本的な設計仕様
3、データベースフィールド設計仕様
4、インデックス設計仕様
5つの一般的なインデックス列の推奨事項
6、インデックス列の順序を選択する方法
7つ目は、冗長なインデックスや重複するインデックスの作成を避けることです。
八、インデックスをカバーすることを優先する
9、インデックスSET仕様
10.データベースSQL開発仕様
11.データベース運用の行動規範
1.データベースコマンドの仕様
・すべてのデータベースオブジェクト名は小文字を使用し、アンダースコアで区切る必要があります
・すべてのデータベースオブジェクト名は、MySQLの予約済みキーワードの使用を禁止しています（テーブル名にクエリのキーワードが含まれている場合は、一重引用符で囲む必要があります）
・データベースオブジェクトの名前はそれらの名前で認識できる必要があり、最終的な数は32文字を超えてはなりません
・一時データベーステーブルには、接頭辞tmp_と接尾辞を付ける必要があり、バックアップテーブルには、接頭辞をbak_と接尾辞（タイムスタンプ）を付ける必要があります。
・同じデータを格納するすべての列名と列タイプは一貫している必要があります（通常、関連付けられた列として、クエリ中に関連付けられた列タイプに一貫性がない場合、データタイプの暗黙的な変換が自動的に実行され、列のインデックスが無効になり、クエリの効率が低下します）
2.基本的なデータベース設計仕様
1.すべてのテーブルでInnodbストレージエンジンを使用する必要があります。
特別な要件（つまり、列ストレージ、ストレージスペースデータなど、Innodbが満たすことができない機能）はなく、すべてのテーブルでInnodbストレージエンジン（mysql5.5）を使用する必要があります。 Myisamは以前はデフォルトで使用され、Innodbは5.6以降のデフォルトです）Innodbはトランザクションをサポートし、行レベルのロックをサポートし、回復性が向上し、高い同時実行性
2でのパフォーマンスが向上します。データベースとテーブルの文字セットはUTF8を均一に使用し、互換性が向上します。統一された文字セットは、文字セットの変換による文字化けを回避できます。比較前に異なる文字セットを変換すると、インデックスが失敗します
。3。すべてのテーブルとフィールドにコメントを追加する必要があります。comment句を使用して、テーブルと列のメモを最初から追加します。データディクショナリを維持するだけです
。4 。単一テーブルデータのサイズを可能な限り制御するようにしてください。500万以内に制御することをお勧めします。500万はMySQLデータベースの制限ではありません。大きすぎると、テーブル構造の変更、バックアップ、および復元に大きな問題が発生します。履歴データアーカイブ（ログデータに適用）、サブデータベース、およびサブテーブル（ビジネスデータに適用）を
使用して、データの量を制御します。5。MySQLパーティションテーブルの使用には注意が必要です。
パーティションテーブルは、物理的に複数のファイルとして表され、論理的に表されます。テーブルのパーティションキーを慎重に選択します。クロスパーティションクエリの効率が低下する可能性があります。テーブルを物理的に分割してビッグデータを管理することをお勧めします。6。
ホットデータとコールドデータを可能な限り分離します。テーブルの幅を狭くします
。MySQLでは、テーブルあたり最大4096列のストレージを制限しています。また、データの各行のサイズは65535バイトを超えることはできません。ディスクIOを減らして、ホットデータのメモリキャッシュヒット率を確保します（テーブルが広いほど、テーブルがメモリバッファプールにロードされるときに占有されるメモリが大きくなり、より多くを消費します。 IO）キャッシュのより効果的な使用、テーブルで頻繁に一緒に使用される無駄なコールドデータの読み取りを回避する（より多くの関連操作を回避するため）
7、テーブルでの予約済みフィールドの確立を禁止する
予約フィールドの名前は名前を識別しにくいです。予約フィールドは保存されたデータタイプを確認できないため、適切なタイプを選択して予約フィールドタイプを変更することができず、テーブルがロックされます。8。
データベースに画像を保存することは禁止されています。 、ファイルおよびその他の大きなバイナリデータ
は通常大きなファイルであるため、短期間にデータが急速に増加します。データベースがデータベースから読み取られると、通常、多数のランダムIO操作が実行されます。ファイルが大きい場合、IO操作は時間がかかり、通常は保存されます。ファイルサーバーでは、データベースはファイルアドレス情報のみを保存します。9。
データベースストレステストをオンラインで行うことは禁止されています
。10。開発環境およびテスト環境から環境データベースに直接接続することは禁止されています。
3、データベースフィールドの設計仕様
1.ストレージのニーズを満たす最小のデータタイプを優先的に選択します。
理由
列のフィールドが大きいほど、インデックス作成に必要なスペースが大きくなるため、ページに保存できるインデックスノードの数が増えます。トラバーサル中に必要なIOの数が少なくなるほど、インデックスのパフォーマンスが低下します
。方法
1）文字列を次のような数値タイプのストレージに変換します。IPアドレスを整数データに変換する。
MySQLには、IPアドレスを処理するための2つの方法があります。
データを挿入する前に、inet_atonを使用してIPアドレスを整数に変換すると、スペースを節約できます。データを表示するときは、inet_ntoaを使用して整数のIPアドレスをアドレス表示に変換します。
2）非負のデータ（自己インクリメントID、整数IPなど）の場合、次の
理由により、符号なし整数がストレージに推奨されます。符号なしは符号付きと比較してストレージスペースを2倍にすることができます
VARCHAR（N）のNは、バイト数ではなく、文字数を表します。
UTF8を使用して、255個の中国語文字Varchar（255）= 765バイトを格納します。長
すぎるとメモリが消費されます。2。TEXTおよびBLOBデータタイプの使用は避けてください。最も一般的なTEXTタイプは64kデータを格納でき
ます。BLOBまたはTEXT列を個別の拡張テーブルに分割することをお勧めします
。Mysqlメモリ一時テーブルはそうではありません。 TEXTやBLOBなどの大きなデータタイプをサポートします。このようなデータがクエリに含まれている場合、メモリ内の一時テーブルは並べ替えなどの操作で使用できず、ディスク一時テーブルを使用する必要があります。
また、この種のデータの場合、Mysqlは2番目のクエリを実行する必要があるため、sqlのパフォーマンスが非常に低下しますが、そのようなデータタイプを使用してはならないという意味ではありません。
使用する必要がある場合は、BLOB列またはTEXT列を別の拡張テーブルに分割することをお勧めします。クエリの際はselect *を使用しないでください。必要な列のみを取得する必要があります。TEXT列のデータが不要な場合は、列のクエリを実行しないでください。
・TEXTまたはBLOBタイプはプレフィックスインデックスのみを使用でき
ます。MySQLにはインデックスフィールドの長さに関する制限があるため、TEXTタイプはプレフィックスインデックスのみを使用でき、TEXT列にデフォルト値を設定することはできません。
3. ENUMタイプの使用を避ける
・ENUM値を変更するにはALTERステートメントを使用する必要があります
・ENUMタイプのORDER BY操作は非効率的であり、追加の操作が必要です・ENUM
の列挙値として数値を使用することは禁止されています
4.すべての列をNOTNULLとして定義してみてください
理由：
・インデックスNULL列は、保存するために余分なスペースが必要なため、より多くのスペースを占有します。
・NULL値は、比較および計算中に特別に処理する必要があり
ます。5。TIMESTAMP（4バイト）またはDATETIMEタイプ（8ワード）を使用します。セクション）保管時間
TIMESTAMPは、1970-01-01 00：00：01〜2038-01-19-03：14：07の時間範囲を格納します。
TIMESTAMPは4バイトを占有し、INTと同じですが、INTよりも読みやすくなり
ます。DATETIMEタイプは、TIMESTAMPの値の範囲を超えるストレージに使用されます。
人々はしばしば文字列を使用して日付タイプのデータを保存します（誤った慣行）：
・短所1：計算と比較に日付関数を使用できない
・短所2：文字列を使用して日付を保存するとより多くのスペースが必要
6.財務に関連金額データは10進型を使用する必要があります。
・非精度浮動小数点：https：//blog.csdn.net/shkfpwzfloat,double
・正確な浮動小数点：10
進10進型は正確な浮動小数点数であり、計算中に精度が失われることはありません。占有スペースは、定義された幅によって決まります。4バイトごとに9桁を格納でき、小数点は1バイトを占めます。bigintより大きい整数データを格納するために使用できます。
第4に、インデックスの設計仕様
1.各テーブルのインデックスの数を制限します。1つのテーブルの
インデックスが5インデックスを超えないようにすることをお勧めします。インデックスは効率を向上させ、効率を低下させる可能性があります。
インデックスを使用すると、クエリの効率が向上しますが、挿入と更新の効率が低下し、場合によってはクエリの効率が低下します。
mysqlオプティマイザーは、クエリの最適化方法を選択すると、統一された情報に従って使用できる各インデックスを評価して、最適な実行プランを生成するためです。同時に多数のインデックスがある場合は、それらをクエリに使用できます。 mysqlオプティマイザが実行プランを生成するのにかかる時間が長くなり、クエリのパフォーマンスも低下します。
2.テーブルの列ごとに個別のインデックスを作成することは禁止されています。
バージョン5.6より前では、1つのSQLでテーブル内のインデックスを1つしか使用できません。5.6以降では、インデックスをマージするための最適化方法はありますが、1つを使用することにはほど遠いです。ジョイントインデックスのクエリ方法は適切です
。3。各Innodbテーブルにはプライマリキーが必要です
。Innodbはインデックスで構成されたテーブルです。データストレージの論理的な順序とインデックスの順序は同じです。
各テーブルは複数のインデックスを持つことができますが、テーブルの格納順序は1つだけです。Innodbは、プライマリキーインデックスの順序でテーブルを編成します。
頻繁に更新される列をプライマリキーとして使用したり、複数列のプライマリキー（ジョイントインデックスと同等）を適用したりしないでください。UUID、MD5、HASH、または文字列列をプライマリキーとして使用しないでください（データの連続的な増加は保証できません）。
主キーには自動インクリメントID値を使用することをお勧めします。
5つの一般的なインデックス列の提案
・SELECT、UPDATE、およびDELETEステートメントのWHERE句に表示される列
・ORDER BY、GROUP BY、およびDISTINCTに含まれるフィールド
1および2のフィールドに一致する列のインデックスを作成しないでください。、通常は、1、2のフィールドの結合インデックスを確立する
ことをお勧めします・マルチテーブル結合の関連する列
6.インデックス列の順序の選択方法
インデックス作成の目的は、インデックスを介してデータを検索し、ランダムIOを減らし、クエリのパフォーマンスを向上させることです。インデックスで除外できるデータが少ないほど、ディスクから読み取られるデータも少なくなります。 。
・最高度の識別は、結合されたインデックスの左端に配置されます（識別=列内の異なる値の数/
列内の行の総数）;・フィールド長が小さい列を結合されたインデックスの左端に配置するようにしてください（フィールド長のため）小さいほど、ページに保存できるデータの量が多くなり、IOパフォーマンスが向上します）。
・最も頻繁に使用される列は、結合インデックスの左側に配置されます（確立できるインデックスが少なくなります）。
7つ目は、冗長なインデックスや重複するインデックスの作成を避けること
です。これにより、クエリオプティマイザが実行プランを生成するのにかかる時間が長くなります。
・重複インデックスの例：プライマリキー（id）、インデックス（id）、一意のインデックス（id）
・冗長インデックスの例：インデックス（a、b、c）、インデックス（a、b）、インデックス（a）
8、カバーするインデックスを優先する
頻繁なクエリの場合は、カバーするインデックスの使用を優先します。
カバーするインデックス：すべてのクエリフィールド（where、select、ordery by、group byに含まれるフィールド）を含むインデックスカバーインデックスです
：
・
Innodbテーブルインデックスの二次クエリを回避するInnodbはクラスター化されたインデックスの順序で格納されますInnodbの場合、リーフノードに格納されているセカンダリインデックスが行のプライマリキー情報です。
セカンダリインデックスによってデータがクエリされる場合、対応するキー値を見つけた後、プライマリキーを介してセカンダリクエリを実行する必要があります。本当に必要なデータを入手してください。カバーリングインデックスでは、すべてのデータをセカンダリインデックスのキー値から取得できます。これにより、プライマリキーに対するセカンダリクエリが回避され、IO操作が削減され、クエリの効率が向上します。
・ランダムIOをシーケンシャルIOに変換して、クエリの効率を上げることができます。
カバレッジインデックスはキー値の順序で格納されるため、IOを多用する範囲検索では、ディスクからデータの各行をランダムに読み取るよりもIOがはるかに少なくなります。カバーするインデックスを使用して、ディスクのランダム読み取りIOをアクセス中にインデックス検索のシーケンシャルIOに変換することもできます。
第9に、インデックスSET仕様
は、外部キー制約の使用を回避しようとします
・外部キー制約（外部キー）の使用は推奨されませんが、テーブルとテーブルの間の関連キーにインデックスを確立する必要があります;
・外部キーを使用して、データの参照整合性を確保できます、ただし、ビジネス側で実装することをお勧めします。
・外部キーは、親テーブルと子テーブルの書き込み操作に影響を与えるため、パフォーマンスが低下します。
X.データベースSQL開発仕様
1.データベース操作にはpreparedステートメントを使用することをお勧めします
。preparedステートメントはこれらのプランを再利用し、SQLコンパイルに必要な時間を短縮し、動的SQLによって引き起こされるSQLインジェクションの問題を解決することもできます。パラメーターのみを渡します。 SQLステートメントを渡すよりも効率的です。同じステートメントを1回解析し、複数回使用して、処理効率を向上させることができます。
2.データタイプの暗黙的な変換を避けます。暗黙的な
変換はインデックスの失敗を引き起こします。例：select name、phone from customer where id = '111';
3.テーブル上の既存のインデックスを最大限に活用します。double
％クエリ条件の使用は避けてください。
たとえば、「％123％」のように（先頭の％がなく、末尾の％のみの場合、列のインデックスを使用できます）
・SQLは
、次のような範囲クエリに複合インデックスの1つの列のみを使用できます。ジョイントインデックスの、b、c列、クエリ条件では、列aの範囲クエリがあり、列aを範囲検索に使用する場合、ジョイントインデックスを定義するときに、列bとcのインデックスは使用されません。この場合は、ジョイントインデックスの右側に列aを配置します。not inは通常インデックス障害を使用するため
、not inoperationを最適化するためにleftjoinまたは
notexistsを使用します。
4.データベースを設計するときは、将来の拡張を検討する必要があります
。5。プログラムは、さまざまなデータベースに接続してさまざまなアカウントを使用し、数字でデータベース間クエリを実行します。
データベースの移行とサブデータベースのサブテーブルの余地を残します
。ビジネスの結合を減らし
ます。権限を回避します。サイズ超過によるセキュリティリスク6.SELECTの
使用は禁止されています* SELECT <フィールドリスト>を使用する必要があります。クエリの
理由：
・CPUとIOおよびネットワーク帯域幅のリソースをより多く消費します。
・カバーインデックスを使用できません
・テーブル構造の変更の影響を減らすことができます
7.次の
ようなフィールドリストなしでINSERTステートメントを使用することは禁止されています：値に挿入（ 'a'、 'b'、 'c'）;
tに挿入を使用する必要があります（c1、c2、c3）values（ 'a'、 'b'、 'c'）;
8.サブクエリの使用を避けます。サブクエリを結合操作に最適化でき
ます。通常、サブクエリはin句とサブクエリにあります。単純なSQL（union、group by、order by、およびlimit句を含まない）の場合にのみ、サブクエリを最適化のために関連するクエリに変換できます。
サブクエリのパフォーマンスが低下する理由：
・サブクエリの結果セットはインデックスを使用できません。通常、サブクエリの結果セットは一時テーブルに保存されます。メモリまたはディスクの一時テーブルにはインデックスがないため、クエリのパフォーマンスに影響します。特定の影響;
・特に比較的大きな結果セットを返すサブクエリの場合、クエリのパフォーマンスへの影響が大きくなります;
・サブクエリは多数の一時テーブルを生成し、インデックスを生成しないため、CPUとIOリソースは、多くの遅いクエリを生成します。
9. JOINを使用して関連付けが多すぎるテーブルは避けてください
。Mysqlの場合、関連付けられたキャッシュがあります。キャッシュのサイズは、join_buffer_sizeパラメーターで設定できます。
Mysqlでは、同じSQLに対して1つのテーブルを結合すると、もう1つの関連付けキャッシュが割り当てられます。SQLに関連付けられているテーブルが多いほど、占有されるメモリが大きくなります。
プログラムで多数のマルチテーブルアソシエーション操作が使用され、join_buffer_size設定が不合理である場合、サーバーメモリのオーバーフローが発生しやすくなり、サーバーデータベースのパフォーマンスの安定性に影響します。
同時に、関連付け操作の場合、一時的なテーブル操作が発生し、クエリの効率に影響します。Mysqlでは最大61のテーブルを関連付けることができるため、5つ以下にすることをお勧めします。
10.データベースとのやり取りの数を減らします。
データベースは、バッチ操作の処理や複数の同一操作の組み合わせに適しているため、処理効率が向上します
。11。同じ列に対応する実行または判断を行う場合
、操作の代わりにinの値を500を超えないようにしてください。インデックスはより効率的に使用できますが、ほとんどの場合、インデックスはほとんど使用されません。
12.ランダムソートにrand（）による順序を使用することは禁止されています。これにより
、テーブル内のすべての適格なデータがメモリにロードされ、ランダムに生成された値に従ってメモリ内のすべてのデータがソートされ、行ごとに1つ生成される場合があります。ランダムな値。条件を満たすデータセットが非常に大きい場合、CPU、IO、およびメモリリソースを大量に消費します。
プログラムでランダムな値を取得してから、データベースからデータを取得することをお勧めします
。13。WHERE句は、関数の変換と
列の計算を禁止します。関数の変換または計算が列で実行される場合、インデックスは使用できません。
・非推奨：
・推奨事項：
14.重複する値がないことが明らかな場合は、UNIONの代わりにUNION ALLを使用します。UNION
は、重複排除操作を実行する前に、2つの結果セットのすべてのデータを一時テーブルに配置します
。UNIONALLは、結果セットを重複排除しなくなります。操作
15.複雑な大きなSQLを複数の小さなSQLに分割する
・大きなSQL：論理的に複雑で、計算に多くのCPUを必要とする
・MySQL：1つのSQLが計算に1つのCPUしか使用できない
・SQL分割が通過できる処理効率を向上させる並列実行
11.データベース操作の実施基準1.100
万行を超えるバッチ書き込み（UPDATE、DELETE、INSERT）操作は、バッチで複数回実行する必要があります
。バッチ操作が大きいと、マスタースレーブの重大な遅延が発生する可能性があり
ます。バッチ操作は、マスタースレーブの重大な遅延を引き起こす可能性があります。大規模な書き込み操作は、通常、実行に一定の時間がかかります。マスターライブラリでの実行が完了した場合にのみ、他のスレーブライブラリで実行されるため、マスターライブラリとスレーブが発生します。ライブラリの長期遅延
・binlogログが行形式の場合、大量のログが生成されます。
大規模なバッチ書き込み操作では、特に行形式のバイナリデータの場合、大量のログが生成されます。行形式では、データの各行の変更が記録されるため、一度に変更するデータが多いほど、生成されるログが多くなり、ログの送信と回復にかかる時間が長くなります。これは、マスタースレーブの遅延の原因でもあります。
・
1回のトランザクションで実行する必要がある大量のデータを変更するための大規模なトランザクション操作は避けてください。これにより、テーブル内の大量のデータがロックされ、大量のブロッキングが発生し、MySQLのパフォーマンスに非常に大きな影響を与えます。
特に、長期間のブロッキングにより、データベースへの使用可能なすべての接続がいっぱいになり、実稼働環境の他のアプリケーションがデータベースに接続できなくなるため、バッチ書き込み操作に注意してください。
2. pt-online-schema-changeを使用して
、大きなテーブルのテーブル構造を変更します。大きなテーブルの変更によって引き起こされるマスタースレーブの遅延を
回避します。テーブルフィールドを変更するときはテーブルをロックしないでください。
大きなテーブルのデータ構造を変更するときは注意が必要です。特に実稼働環境で深刻なロックテーブル操作を引き起こすことは許容できません。
pt-online-schema-changeは、最初に元のテーブルと同じ構造の新しいテーブルを作成し、新しいテーブルのテーブル構造を変更してから、元のテーブルのデータを新しいテーブルと元のテーブルにコピーします。いくつかのトリガーを追加します。
元のテーブルに新しく追加されたデータを新しいテーブルにコピーします。行のすべてのデータがコピーされた後、新しいテーブルに元のテーブルという名前が付けられ、元のテーブルが削除されます。
元のDDL操作を複数の小さなバッチに分解します。
3.プログラムが使用するアカウントにスーパーパーミッションを付与することは禁止されています。
接続の最大数に達すると、スーパーパーミッションを持つユーザーも接続を実行します。スーパーパーミッションは、問題に対処するためにDBAが使用するアカウントに対してのみ予約できます。
4.プログラムがデータベースアカウントに接続するには、最小特権の原則に従い
ます。プログラムで使用されるデータベースアカウントは、1つのDBでのみ使用できます。クロスデータベースプログラムでの使用が許可されていないアカウントには、原則としてドロップ権限を付与できません。