まず、データベースコマンドの仕様
・ すべてのデータベース・オブジェクト名は、小文字と下線の部門でなければなりません
・ すべてのMySQLデータベース・オブジェクト名は、予約キーワードの使用を禁止（テーブル名がキーワードクエリを含んでいる場合、それは単一引用符で囲む必要があります）
・ 知名度が行うことに意図されて見ることができるように、データベース・オブジェクトに名前を付けて、32文字を超える続かないでください
・ 一時データベーステーブルは、日付が付いや接尾辞TMP_必要があり、バックアップテーブルはbak_と日付（タイムスタンプ）のサフィックスを付ける必要があり
* すべてのデータは、同じ列名とタイプに格納されている同じでなければならない（クエリの自動データ型の暗黙的な変換は、クエリ効率の低下につながる、列のインデックスの故障につながる場合の一般的な関連列として、列タイプの関連付けが矛盾することになります）
第二に、基本的なデータベースの設計仕様
1.すべてのテーブルはInnoDBストレージエンジンを使用する必要があります。
特別な要件は（つまり、InnoDBはなどの機能会いません：列ストレージ、データストレージなど）の場合に、すべてのテーブルには、（デフォルトのInnoDBとして5.6後mysql5.5前にデフォルトのMyISAM、）のInnoDBトランザクションをサポートしInnoDBストレージエンジンを使用する必要があります。 、行レベルのロック、より良好な回復、高い並行性の下で良好な性能をサポートします。
2、データベースとテーブルは、文字一貫して使用UTF-8に設定します
より互換性、統一された文字セットが原因化け文字セットの変換に回避することができ、比較前に、異なる文字セットを生産し、変換が失敗インデックスになりますが必要です
3、すべてのテーブルとフィールドがコメントを追加する必要があります
データ辞書を維持するために、最初からノートのテーブルと列を追加するコメント句を使用します
4、データの単一のテーブルの大きさの量を制御しようとすると、以下の500万でコントロールをお勧めします
500万制限は、MySQLデータベースではありません、総会の原因、バックアップの上にテーブル構造を変更し、回復が大きな問題を持っています
過去のデータ、サブライブラリーサブテーブル（業務データに適用される）とデータの量を制御するための他の手段で（ログ・データに使用される）アーカイブすることができ
5、MySQLのパーティションテーブルを注意深く使用
複数のファイルのような物理的な性能上のパーティションテーブルは、慎重に選択テーブルの性能は、論理パーティション・キー、パーティションクエリ効率が大きなデータテーブルの管理の物理的分離の提案された方法を横切って低くてもよいです
6、限りホットとコールドデータの可能な分離、テーブルの幅を減少させるよう
MySQLの各テーブル記憶4096を制限し、データの各行のサイズはIO 65535バイトを超えることはできませんが、ディスクを減らす場合、メモリ・キャッシュ（表広い、テーブルが占有メモリ・バッファ・プール・メモリにロードされた熱データを確保するためにヒット率大きく、キャッシュのよりIO）より効率的な使用を消費する、読み出し用カラムは、無駄なデータを回避することが多い）、さらに、関連動作を回避するために、（表の中に冷たいで使用され
図7は、テーブル内の予約フィールドの設立を禁止します
予約済みフィールドの命名は、司法予約フィールド名識別はデータ型が格納されて確認することはできませんを参照することは非常に困難であり、それは予約フィールドタイプへの変更の権利の種類を選択することは不可能である、テーブルがロックされます
8、データベース内の画像、文書を保存するために大規模なバイナリデータを禁止
ファイルが大きい場合は通常のファイルにのみ、通常のファイルサーバに保存され、通常、データベースが読み込まれるときに、短時間でデータの量は、データベースの急速な成長を引き起こす可能性があり、データベースに格納時間のかかる操作IOランダムIO操作の多くは大きいですアドレス情報ファイル
9、ストレステストを行うには、オンラインデータベース上禁止
開発環境から禁止10は、テスト環境は、直接接続された世代のデータベース環境であります
第三に、設計仕様のデータベースフィールド
図1は、好ましいデータ型は、最低限必要なストレージと一致します
・理由
大きな列フィールド、必要横断しながら索引付けのために必要なスペースも大きく、ノードのインデックス番号は、ページ少ない未満、よりIOの数に格納することができます性能指標も悪化し
・メソッド
整数データにIPアドレスを変換する：1）のような、デジタル方式のメモリに文字列を変換します。
MySQLは、IPを処理するために2つのメソッドを提供します。
符号なし整数にINET_ATON IP（4-8）
整数のIPアドレスへのINET_NTOA
整数に最初のIPアドレスINET_ATONで、データを挿入する前に、スペースを節約することができます。アドレスにIPアドレスINET_NTOA整数を用いた表示データは、表示することができる場合。
2）負でないデータ（例えば、IDは整数IP、インクリメント）について、優先順位が符号なし整数を使用して格納されています
なぜなら：符号なし相対シンボルは倍以上のストレージ容量を有することができます
SIGNED INT -214748648〜2147489647
UNSIGNED INT 0〜4294967295
NのVARCHAR（N）は、文字の数ではなくバイト数を表します
255の文字は、UTF8 VARCHAR（255）= 765バイトに格納されています。過度の長さは、より多くのメモリを消費します
2、TEXT、BLOBデータ・タイプの使用を回避は、テキストデータの最も一般的なタイプは、64Kに格納することができます
・ 独立した拡張テーブルのBLOBまたはTEXT列に分離すること推奨
クエリは、このようなデータを含んで並べ替えやその他の操作時に、あなたは、あなたが一時的なディスク・テーブルを使用する必要がありますメモリの一時テーブルを使用することができない場合、MySQLのメモリの一時テーブルには、TEXT、このような大規模なようBLOBデータ型をサポートしていません。
そして、このデータのために、MySQLや二次のクエリには、SQLパフォーマンスが悪くなり、私たちは、このようなデータ型を使用できないことを言わないだろう。
あなたが使用する必要がある場合、それは別の拡張テーブルに別のBLOBやTEXTカラムに推奨され、選択クエリを使用してはならない*だけで、必要な列を削除する必要があり、列はデータTEXT列を照会する必要はありません。
・ TEXTまたはBLOB型はプリフィックス索引を使用することができます
MySQLのインデックスフィールドの長さが限られているので、これだけTEXTタイプのプレフィックスのインデックスを使用し、そしてTEXTカラムはデフォルト値を持つことができません。
3、ENUM型の使用を避けます
・ 変更ENUM、ALTERステートメントを使用します
・ 業務の効率化、追加の操作を必要とすることにより、低ENUMタイプORDER
・ ENUM列挙値として値の使用を禁止します
NOT NULLとして定義され4、可能な限りすべての列
理由：
・ インデックスNULL列はので、より多くのスペースを取るために、それらを維持するために追加のスペースを必要とします。
・ NULL値のための特別な取引を行うために比較して計算されています
5、TIMESTAMP（4バイト）またはDATETIME型（8バイト）蓄積時間を用いて
07：14：TIMESTAMP時間1970-01-01午後12時00分01秒〜2038-01-19-03を保存
TIMESTAMP 4つのバイトと同じINT、INTが、読みやすさよりも高いを占めています
DATETIME使用されるストレージの種類の範囲を超えTIMESTAMP。
店舗の日付（ない正しい道）への文字列データ型を持つことが多いの誰か：
・ 一つの欠点：計算され、日付関数と比較することはできません
・ 欠点2：より多くのスペースを取るために文字列を格納されている日付
6、金融関連のクラスの量と小数点データ型を使用する必要があります。
* 非精度浮動小数点：float型、ダブル
・ プレシジョン浮動小数点10進
小数精度の浮動小数点型は、計算の精度を失うことはありません。定義された幅によって決定空間は、1つのバイト毎に4つのバイト9つの数字と小数点を格納することができます。整数データを格納するために使用することができるよりも大きいBIGINT。
第四に、インデックスの設計仕様
1、単一のテーブルのインデックスが5以上のものをお勧めしませんが、各テーブルにインデックスの数を制限
インデックスがない方が良いです！効率を向上させることができインデックスも効率を低下させることができます。
インデックスは、クエリの効率を向上させることができ、また、挿入および更新の効率が低下し、さらにいくつかの例では、クエリの効率が低下します。
クエリ、ベースのユニファイドメッセージングを最適化する方法を選択する際に、照会するために使用することができ、同時に複数のインデックスがある場合、MySQLのオプティマイザので、各インデックスは、最適な実行計画を生成し、評価するために使用することができ、時間は、MySQLのオプティマイザが実行計画を生成増加します、それはまた、クエリのパフォーマンスが低下します。
図2に示すように、テーブル内の各列に禁止する個別のインデックスを確立しています
バージョン5.6以前は、インデックスのみのクエリの共同使用からまだ遠くでも組み合わせインデックス最適化された方法で、5.6の後に良いテーブルへのインデックスを、使うことができますが、SQL
3、各InnoDBのテーブルは主キーを持っている必要があります
InnoDBは索引構成表である：論理順序と順序インデックス格納されたデータは同じです。
各テーブルには、複数のインデックスを持っているが、唯一のInnoDBに主キー索引構成表があることを順に順位テーブルを記憶することがあります。
主キーとして頻繁に更新列を使用しないでくださいするUUID、MD5、HASH、主キーとして文字列の列を使用しないでください（共同インデックスに相当）複数列の主キーには適用されません（データの順で成長を保証するものではありませ）。
推奨インクリメントの主キーID値。
第五に、一般的なインデックス列の提案
・ 列にDELETE文、SELECT、UPDATEのWHERE句で表示されます
・ フィールドは、ORDER BY、GROUP BY、DISTINCT内が含まれています
共同インデックスフィールド1と2を確立するために、インデックス、通常より良いを確立している列フィールド1と2を満たすために望んでいません
・ マルチテーブルは、関連の列に参加します
6、どのようにインデックス列の順序を選択します
インデックスの目的は次のとおりです。私は、インデックスによって、インデックスが少ないデータを読み取るために、ディスクからの少ないデータをフィルタリングすることができ、ランダムIOを削減するクエリのパフォーマンスを向上させるために、データを見つけることを願っています。
・ 最高合わせ左端インデックスに差別（=カラム/列の異なる値の識別番号の行数）。
・ 可能な限り最も左の関節指数のカラムの小さなフィールド長さ（より小さいフィールド長ため、より大量のデータを格納することができ、IOのより良い性能）。
・ 最も多くの共同インデックスに左の列で使用される（あなたは、インデックスの比較的少数を確立することができます）。
七、冗長性と重複インデックスインデックスを作成しません
これは時間を増やすれるようにクエリオプティマイザは、実行計画を生成します。
反復指数例：主キー（上記ID）、インデックス（上記IDを述べ）、UNIQUEインデックス（上記ID言及）
・実施例冗長度：インデックス（A、B、C）、インデックス（A、B）、インデックス（A）
8つのプライオリティ・カバレッジ・インデックス
頻繁に照会するための優先順位は、カバリングインデックスを使用します。
被覆率：すべてのクエリフィールドを含む（による選択、ordery、によってグループフィールドを含む）インデックス
インデックスの利点をカバーします：
・ InnoDBのセカンダリインデックステーブルクエリを避けてください
INNODBクラスタ化インデックスは、リーフノードに格納された2つのインデックスが、情報ラインの主キーであり、InnoDBのために、順に記憶されています
あなたがデータを照会するセカンダリインデックスを使用している場合は、適切なキーを見つけた後、私たちは、主キーで2番目のクエリを行うために必要な実際のデータを取得する必要があります。カバーインデックスは、インデックスの二つの重要な値は、検索効率を向上させる、IOオペレーションを低減、プライマリクエリの二次キーを避け、すべてのデータを取得してもよいです。
・ クエリの効率を加速するためのランダムIO IOの順になることができます
被覆率が集中IOの範囲はルックアップのために、キー値の順に格納されているので、各ラインのIO比較ランダム・アクセス・データは、ディスクからはるかに小さくなるように、そうカバーインデックスの使用はまた、ランダムにディスクにアクセスすることができIO IOは、インデックス検索の順に読み込みます。
九、SET指数の仕様
外部キー制約を使用しないでください
・ 外部キー制約（外部キー）を使用することをお勧めしないが、それは、テーブルとテーブルの間に関連した債券にインデックスを作成する必要があります。
・ 外部キーは、データの参照整合性を確保するために使用することができるが、ビジネスの目的を達成することをお勧めします。
・ 外部キーは、親と子テーブルは、それによって性能が低下する書き込み動作に影響します。
テン、SQLデータベースの開発仕様
1、データベース操作のために準備されたステートメントを使用することをお勧めします
プリコンパイルされた文はSQLをコンパイルするために必要な時間を短縮、計画を再利用することができ、また、唯一のパラメータを渡すSQLインジェクションによって引き起こされる問題を解決するため、一度に解析することが可能SQLステートメントと同じステートメントよりも効率的に渡すことができ、動的SQLは、何度も使用し、処理効率を向上させます。
図2に示すように、データ型の暗黙的な変換を避けます
暗黙的な変換は、インデックスの故障につながることができます。以下のような：ID =「111」を選択し、名前、電話顧客から。
3、既存のテーブルインデックスをフルに活用
・ ダブル％の問い合わせ番号を使用しないでください。
LIKE「％123パーセント」として、（NOフロント場合％、リア％のみが、列のインデックスに使用することができます）
・ SQLは、複合インデックス範囲クエリを実行するために使用することができます
例えば：関節指数、B、列C、関節指数を定義するときにカラムがあることならば、Bに、C列インデックスは、使用されない、クエリ条件の範囲クエリが記載されています範囲を見つけるために使用される、あなたは、列の共同インデックスの右側に置く必要があります。
左ではない参加したり、使用して、動作していない最適化するために存在します
使用インデックスでも、多くの場合、失敗しないため。
4、データベース設計は、将来の拡張のために考慮されるべきです
異なるデータベースを接続する5は、別のアカウント、六角クロスデータベースクエリを使用します
・ ライブラリデータベースの移行とサブサブテーブルのための休暇の部屋
・ カップリング事業の程度を削減
・ セキュリティリスクから生じる過度の権利を避けてください
あなたはSELECT <フィールドリスト>クエリを使用する必要があります* 6、SELECTの使用を禁止
理由：
・ ネットワーク帯域幅をより多くのCPUとIOリソースを消費
・ カバーインデックスを使用することはできません
・ チェンジ・テーブル構造の影響を低減するために、
7、フィールドのリストが含まれていないINSERT文の使用を禁止
如：値（ 'A'、 'B'、 'C'）に挿入します。
使用T（C1、C2、C3）の値（ 'A'、 'B'、 'C'）に挿入します。
8は、サブクエリの使用を避けるには、業務に参加するためにクエリオプティマイザを扱うことができます
通常、クエリ内のサブ句、およびサブクエリでは、単純なSQLが（組合によるグループ、LIMIT句による順序が含まれていません）で、クエリの最適化に関するお問合せを処理するために変換することができます。
パフォーマンス低下の原因サブクエリ：
・ 一時テーブルまたはディスク・メモリの一時テーブルはインデックスが存在しないかどうか、インデックスを使用することはできませんサブクエリの結果セットが、結果は、通常、サブクエリのセットが一時テーブルに格納されている、クエリのパフォーマンスがある程度影響を受けることになります。
・ 特にリターン結果セット比較的大きなサブクエリ、クエリのパフォーマンスに大きく、その影響のために、
・ 一時テーブルの多くが生成されますサブクエリがインデックスを持っていないので、それは遅いクエリの大多数で、その結果、過度のCPUとIOリソースを消費します。
9、あまりにも多くの関連テーブルをJOINを使用しないよう
MySQLの場合、連想キャッシュの有無、キャッシュサイズがパラメータjoin_buffer_sizeによって設定することができるです。
MySQLでは、同じSQLマルチ関連付けるためのテーブル（結合）は、マルチ連想キャッシュ、SQL、メモリの複数の関連テーブルであれば、より多くの量を割り当てます。
不合理join_buffer_sizeセットの場合には、サーバのメモリオーバーフローを引き起こすことは容易である一方、プログラムは、マルチテーブルの操作に関連する使用の多くの場合は、サーバーのデータベースのパフォーマンスの安定性に影響を及ぼします。
関連動作のために同時に、操作を5上に推奨されない61のテーブルの最大値に関連付けられた一時テーブルは、MySQLクエリ効率への影響を、生成します。
図10は、データベースとの相互作用の数を減らすこと
併せて、処理効率が同じバッチ処理を複数のより適切なデータベース処理動作を向上させることができます
判定が同じ列に対応する、またはの代わりにまたはに使用11、
動作していない500以上の指標をより効率的に利用価値の、またはほとんどの場合、インデックスを使用することはほとんどありません。
12、ランド順の使用を禁止（）は、ランダム配列決定
テーブルは、メモリ内にすべての修飾されたデータをロードし、次にメモリ内のすべてのデータのためにランダムに生成された値に従ってソートし、データセットの状態が非常に大きい場合、各行は、ランダムに生成された値を有することができるであろうそれはCPUとIOやメモリリソースを大量に消費します。
プログラムにランダムな値を得ること、及びそのような方法でデータベースからデータを取得お勧め
句が列を変換する機能を禁止し、算出し13、
これは、列が変換や計算の関数であるとき、インデックスが使用できない原因になります。
*推奨しません：
どこ日付（CREATE_TIME）= '20190101'
・推奨：
どこCREATE_TIME> = '20190101' とCREATE_TIME < '20190102'
UNION ALLを使用すると、明らかに代わりにUNIONを値を重複しない14、
・ データ重複除外のUNIONのすべてが一時テーブルに2つの結果セットを操作しますについて
・ UNION ALLを再作動するように設定された結果ではありません
15、いくつかの小さなSQLに大規模、複雑なSQLを分割
* 大規模なSQL：複雑なロジック、SQLのCPU集中型の計算
・ MySQLの：SQLは、1つのCPUのみを使用することができますが計算されます
・ SQLこの分割は、並列実行を介して処理効率を向上させることができます
XI、行動のデータベース操作コード
複数のバッチを動作させるためのバッチ書き込み（UPDATE、DELETE、INSERT）動作100万行を超える1、
・ ハイボリューム操作は、マスターからの深刻な遅延を引き起こす可能性があり
マスター・スレーブ環境、ハイボリュームの操作は深刻なマスタースレーブの待ち時間が発生することがあり、大量の書き込みは、一般的にある程度の時間を実行するために必要な、そして唯一のメインライブラリの実装が完了した後、そう、他にライブラリから実行されますこれは、メインのライブラリと長いライブラリから遅延が発生します
・ 行フォーマットをBINLOG時にログのログの多くを生成します。
行フォーマットがデータの各行を変更記録されるので、大量の書き込みは、特にバイナリデータ形式の行のため、大きなログが生成され、より多くの時間我々はデータを修正、生成されたログの量も、それ以上であろう遅延の主な理由によって引き起こされる長いために必要な時間伝送および回復ログ。
・ 大規模なトランザクション操作を避けます
これにより、大幅な閉塞を引き起こし、ロックされているテーブル内の大量のデータになります単一のトランザクションで行わなければならないデータ、大量の変更は、MySQLのパフォーマンスに非常に大きな影響がブロックされます。
特に長時間の接続がデータベースに接続できない、他のアプリケーション環境の生産を行い、利用可能なすべてのデータベースを埋めるため、バッチで行うことが大量の書き込み操作に注意を払うようにしてくださいますブロックされました。
PT-オンライン・スキーマ変更修正テーブル構造を使用して大規模なテーブルのための2、
・ メイン遅れから生じた大きなテーブルの変更を避けます
・ 変更するフィールドのテーブルにロックテーブルを避けてください
注意しなければならないデータ構造を変更するための大きなテーブルには、特に本番環境では、許容できない、深刻なロックテーブル操作を引き起こします。
PT-オンライン・スキーマの変更は、それが最初の新しいテーブルに新しいテーブルの同じ元のテーブルの構造、および変更テーブル構造を確立し、新しいテーブルに元のテーブルのデータをコピーし、元のテーブルになりますいくつかのトリガーを追加します。
新たなデータで元のテーブルはまた、全てのデータが終了したコピーした後、新しいテーブル、行に元のテーブルに新たなテーブルをコピーし、元のテーブルを削除します。
複数のより小さなバッチに元のDDL操作。
3、スーパープログラムで使用されるアカウントのアクセス許可を与えることを禁止
接続数の制限の最大数は、また、超特権を接続し、スーパーユーザー権限を実行したときにのみDBAアカウントを使用して問題に対処するために残すことができます。
4、データベース・アカウントに接続するための手順、最低限の権利の原則に従ってください
プログラムは、プログラムによって使用されるクロスデータベースはドロップ権限を持っている唯一のDBで使用することができ、原則として、準アカウントが許可されていないデータベース・アカウントを使用しています。