MySQLのクエリプロセス図
なぜ最適化
- システムのスループットのボトルネックは、多くの場合、データベース・アクセス・スピードに表示されます
- アプリケーションが実行されているように、データベース内のデータがより多くなり、処理時間が遅くなります
- データはディスク上に保存され、そしてメモリの読み書き速度は比較することはできません
最適化する方法
- データベーステーブル、デザインの分野、ストレージエンジン：データベースを設計するとき
- など、インデックス、などのMySQL自体によって提供される機能をうまく利用し、確認します
- スケール：MySQLのクラスタリング、ロード・バランシング、別の読み取りおよび書き込み
- （ほとんど成功し）SQL文の最適化
まず、フィールド設計フェーズ
最も適切なフィールドプロパティを選択
1フィールドの幅はできるだけ小さく設定します
MySQLはまた、より高速になり、データアクセス、大量の良い支援することが、一般的に言って、データベース内の小さなテーブル、その上でクエリを実行することができます。テーブルを作成するときにそのため、より良いパフォーマンスを得るために、我々は可能な限り小さく、テーブル内の列の幅を設定することができます。
NOTNULLにしようとする2フィールド
可能で、フィールドはNOTNULLに設定されて維持しようと、クエリを実行するには、この時点では、データベースは、将来的にNULL値を比較する必要はありません。
3.データの型がENUMとして定義される決定
こうした「地方」や「性別」など、いくつかのテキストフィールドについては、我々は、ENUMタイプとしてそれらを定義することができます。MySQLでいるので、ENUM型は数値データ、数値データと、それはテキストタイプを処理しているよりもはるかに速い速度として扱われます。このように、我々は、データベースのパフォーマンスを向上させることができます。
表4つのフィールドが過剰であってはならない、フィールドは予約されてもよいです
前提は、ビジネスは、2つまたは3つのフィールドをニーズを満たすためにあるフィールドの拡張を容易にするために取っておくことには限界があります。
設計仕様のデータシートをフォロー
1.最初のパラダイム（1NF）
フィールド値は、アトミックである（第1正規形内のすべてのリレーショナルデータベースシステム）を細分化しない、例えば：名前フィールド、全体として前記最初と最後の名前、姓と名が2つの別々のフィールドを区別する場合に設定する必要があります。（フィールド不可分）。
2.第二のパラダイム（2NF）
注;表は、一意の取引を行ことができる識別する主キーを持つ必要があります：最初に通常形成しなければならないが、（主キー、非主キーフィールド依存プライマリキー）。
3.第3正規形（3NF）
テーブルにはアフリカのその他の関連情報テーブルのキーフィールドを負担することはできません、すなわち、データテーブルは、シェンフィールドよりも多くを持つことができません。注：あなたが第一、第二のパラダイムを満たさなければならない;（非プライマリキーフィールドが相互に依存することはできません）
第二に、ストレージエンジンを選択します
MyISAMとInnoDBの比較
- InnoDBのサポートのものが、MyISAMテーブルは物事をサポートしていません。
- InnoDBは、行レベルのロックをサポートし、MyISAMテーブルレベルのロックをサポート
- InnoDBのサポートMVCC（マルチバージョン同時実行制御、楽観的ロックの実装よりもより多くの何も）、およびMyISAMテーブルはサポートしていません。
- サポートInnoDBの外部キー、およびMyISAMテーブルはサポートしていません。
- InnoDBは、フルテキストインデックス、およびMyISAMのサポートをサポートしていません。
第三に、インデックス
インデックスとは何ですか
鍵データとの間のマッピング関係は、インデックス（キー== ==含むアドレスとディスクにおける対応するレコード）と呼ばれます。キーワードは、検索されたデータのうち特定のコンテンツを識別するためのデータから抽出されます。
インデックスはなぜ速いです
- データ自体は、少量のデータに対してキーワード
- 注文されているキーワードは、バイナリ検索が素早く位置を決定することができます
インデックスタイプ
- 一般インデックス
key（） - ユニークインデックス
unique key（） - プライマリキーインデックス
primary key（） - フルテキストインデックス
fulltext key（）
インデックスインデックスの三種類は同じですが、異なるキーワードインデックスの制限があります。一般的なインデックス：キーワードに制限はありません。唯一のインデックス：レコードキーワードを提供を繰り返すことはできません。主キーのインデックス：唯一の主要な要件がnullではありません
第四に、キャッシュクエリ
開くかどうかを確認してください
オープン操作
窓があるmy.iniのLinux上でmy.cnf
[mysqld]セグメント構成query_cache_type：
- 0：開けないでください
- 1：ON、デフォルトのキャッシュはすべて、SQL文を増大させる必要は
select sql-no-cacheキャッシュを放棄するように要求しました - 2：デフォルトのキャッシュを開き、SQLステートメントを大きくする必要がない
select sql-cache積極的（一般== ==）をキャッシュするために
クライアントのキャッシュサイズに設定
开启缓存之后设置缓存大小：set global query_cache_size=64*1024*1024;
キャッシュの無効化問題（大きな問題）
データテーブルの変更は、キャッシュがデータテーブルのいずれかに基づいて行われます場合には削除されます。（表レベルの管理ではなく、管理のレコードレベルので、より高い故障率）
注意事項
- アプリケーションは、懸念すべきではない
query cache状況の使用。あなたは試しすることはできませんが、query cacheとして、ビジネスロジックの決定query cacheDBAによって管理されます。 - キャッシュは、鍵保管のためのSQL文なので、複数のスペースや大文字小文字の違いが試合になります場合でも、同じSQL文の機能場合ではなく、キャッシュすること。
V.パーティション
私たちが作成する通常の状況下の表は、保存されたファイルのセットに対応し、使用MyISAM時間をストレージエンジンである.MYIと.MYD、ファイル、使用Innodb時にストレージエンジン.ibdと.frm（テーブル構造）ファイル。
大量のデータを（通常は、レコードの数百万人のレベルを超えて）、MySQLのパフォーマンスが低下し始めます場合は、次に我々は、ファイルの複数の組の間でデータを格納する必要があり、その個々のファイルの効率性を確保します。
作成は、パーティションを作成します。
表示dataカタログ：
テーブルのパーティショニングのサービス側がクライアントに対して透過的で、クライアントデータは、いつものように挿入されているが、サーバーは分割アルゴリズムの分散液中のデータを保存します。
MySQLのパーティショニングアルゴリズムが提供します
フィールドの分割は、主キーの一部である必要があり、パーティションを迅速に、データを見つけるような強い検索フィールド、またはフィールドパーティション無意味に従うべきである高い周波数のフィールドを検索することです。
- ハッシュ（フィールド）：同じ入力が同じ出力を得ることができます。法律は何の関係もないかどうかの入力と出力との結果。== ==のみ整数フィールドの
- キー（フィールド）と
hash(field)同じ特性のみkey== ==文字列処理、特定のhash()多段階でモジュロ演算を計算する文字列から整数を行います。 - レンジアルゴリズム：データによるアルゴリズム== ==条件のパーティション、パーティションのサイズ範囲（データは異なるパーティションに、特定の条件を使用して）。
- リスト・アルゴリズム：パーティションが値パーティションのリストによると、また、条件です（
in (值列表)）。
パーティションを使用してください
データテーブルの大規模な量が、パーティションを持参すると効率の向上が明らかにされます。
唯一の検索フィールドにはパーティションフィールドで、パーティションは、効率性の向上をもたらし、より明らかであろう。したがって、選択は== ==パーティションフィールドは非常に重要であり、ビジネス・ロジック== ==（クエリとして可能な限りパーティションフィールド）を可能な限り調整区分フィールドを作成します。
シックス・クラスター
マスタースレーブのレプリケーション
別々の読み取りおよび書き込み（マスター・スレーブに基づきます）
ロードバランシング
- 投票
- WRR：処理能力に応じて重み付け
- 負荷分散：現在フリーの状態によると（ただし、メモリなどの使用状況、各ノードのCPU使用率を、テストする最も忙しい1を選択するために比較するか、効率が低すぎます）
ハイアベイラビリティ
ときにサーバ・アーキテクチャ、何のサーバーのダウンタイムは、オンライン、各サーバーの冗長機を提供する（例えば書き込みサーバー、データベースミドルウェアとして、サーバーが提供するサーバー）のための単一のポイントを必要としない7X24ことを確実にするためです。
サーバのヘルス（書き込み - 冗長ハートビート経由）を書くときに冗長サーバ、 - 書き込みサーバの場合は、同様の書き込みを提供する必要性が、書き込み - 冗長性をコピーを行うにはその役割から、コンテンツサーバマシンを書いて同期、サーバが書き込みにダウンしたときに、書き込み - サーバを冗長するトップは、書き込みサーバとして機能していきます。このプロセスは透明であり、外の世界に、それが唯一のIPを介してサービスにアクセスし、外の世界です。
七つの典型的なSQL
オンラインDDL
DDL（データベース定義言語）が定義されたデータベースのテーブル構造（あるcreate table）とメンテナンス（alter table言語）。下に、オンラインDDLを実行して、MySQL5.6完全なテーブルにつながる-timeバージョンが排他的にロックされ、このタイムテーブルは、その期間のすべてのアクセスのテーブルに応答しないにつながることができ、メンテナンス、非動作状態、です。しかし、MySQL5.6サポート、後にOnline DDL、大幅にロック時間を短縮。
DDL最適化技術は、テーブル構造維持する（例えば増加などをまたはインデックスを追加）するために使用され、戦略== ==コピーです。アイデア：小時間は== ==コンテンツロック（ロックされたが、データがインポートされている）ことを保証するために、新しいテーブルにインポート（コピー）を一つずつ古いテーブルデータ== ==、新しい構造を満たすために新しいテーブルを作成します、あなたは古いテーブルの上に他のタスクを実行することができます。インポートが完了した後、インポート処理中に、ログの形式で記録された古いテーブルのすべての操作のために、更新ログは、（一貫性を確保するために）新しいテーブルの上にそれを再度実行します。最後に、新しいテーブルが古いテーブルを置き換える（アプリケーションを完了、または完了データベース、ビューの名前を変更）。
しかし、MySQLのアップグレードで、この問題はほとんどフェードアウトされます。
データベースのインポート文
データを復元するときは、大量のデータをインポートすることがあります。この時点で、すぐにインポートするために、あなたはいくつかのヒントを持っている必要があります：
輸入のインデックスと制約を無効にします。alter table table-name disable keys
インポートするデータが終了した後、その後、インデックスと制約を回し、インデックスを作成するために、ワンタイム：alter table table-name enable keys
- あなたは、データベースエンジンを使用している場合
Innodb、それは（また、一定の時間を消費する）各トランザクションプラス==について==書き込み命令をデフォルト設定されます、手動でトランザクションを開き、一括インポートに最後マニュアルの一定量を実行することをお勧めしますトランザクションをコミットします。 - SQLの一括インポートが同じ形式が異なるデータでコマンド場合は、必要がある
prepareことは、コンパイルを繰り返すように多くの時間を節約することができますので、事前にコンパイルについて== ==します
リミットオフセット、行
何も大きなことを確実にしてくださいoffsetなど、limit 10000,10ラインの同等の数は、チェックアウト前に廃棄されていない10000ライン、次に取る10ラインを、プラスの条件の数はそれ（完全なスクリーニング）をフィルタリングすることができ、かつ使用すべきではないlimitデータへのクエリをスキップします。これは==であるoffset有用な作業==問題を行います。大きなページを避けるために、実際のプロジェクトに対応し、条件フィルタを実行するためにユーザをガイドしてみてください。
*あまり使用することを選択します
それは、彼らが必要とするフィールドを選択しようとしているselectが、影響は、ネットワークの伝送より数十バイトの数百あまり遅れ、今人気のORMフレームワークを使用しているのではなく、素晴らしいですselect *が、私たちはテーブルをデザインなお、このような製品の詳細などのデータフィールドの大量の分離は、単一商品の詳細テーブルの外に引き出すことができるので、あなたはページの短い商品を表示するときに読み込み速度は影響しません。
ランドによるオーダー（）を使用しないでください
それは論理的なランダム順序である（それぞれのデータが乱数、乱数は、次にサイズに応じてソートされる生成します）。select * from student order by rand() limit 5それが各データテーブル用の乱数を生成し、我々直前5をソートするので効率は、非常に低いです。
溶液：アプリケーションでは、主キーがランダムマスターキー検索を使用してデータベースに、優れた生成します。
シングルテーブルとマルチテーブルのクエリ
マルチテーブルクエリ：joinサブクエリは、マルチテーブルのクエリに関連しています。あなたが使用している場合はexplain、あなたがマルチテーブルクエリを見つける実施計画の分析を加工テーブルのテーブル、合併の最終的な結果です。そこで我々は、データベース上に置かれた圧力を計算するためのアプリケーション、およびマルチテーブルのクエリの上に置かれた圧力を計算するために単一テーブルのクエリを言うことができます。
（シングルテーブル、クエリ、外部キーが自動的に関連テーブルを照会するために行くがある場合、テーブルは捜査の表では）私たちは単一テーブルのクエリオブジェクトのマッピングがもたらす問題を解決するために、今ORMフレームワークを持っています。
カウント（*）
ではMyISAM、ストレージエンジンは、自動的にテーブルの行数、使用記録しますcount(*)速いリターンを。Innodbインテリアは、そのようなカウンタは、我々は手動でレコード数をカウントする必要はないです、アイデアだけでは解決するために、テーブルを使用することです：
リミット1
あなたが唯一の決定を取得できた場合は、追加提案しlimit 1、実際に、私たちは（単一のクエリ操作が自動的に追加されます、これを行うのに役立つORMフレームワークをlimit 1）。
八、スロークエリログ
実行時間を記録するために使用されるSQLログの特定の臨界値、速い位置決めのためのスロークエリ、私たちの最適化への参照を超えています。
スロークエリログをオンにします
設定slow_query_log項目：。
それは使用することができますshow variables like ‘slov_query_log’開いている場合、ステータス値があれば、確認するためにOFF使用することができますset GLOBAL slow_query_log = on開くために、それがされますdatadir下の生成xxx-slow.logファイルを
重要な時期を設定します
設定項目：long_query_timeの
表示：「long_query_time」のようなショーの変数は、秒単位で
設定します。set long_query_timeを= 0.5
リアルタイム動作が短時間からの時間に設定する必要があり、離れて最適化された最も遅いSQLについてです。
ログの表示
SQLは、重要な時間を超えると、我々は、それが記録されますセットxxx-slow.logに。
九、プロファイル情報
オープンプロフィール
オンにすると、より多くの情報は、すべてのSQLの実行が自動的に記録されます
プロファイル情報を見ます
QUERY_IDによってSQL時間のいずれかですべての詳細な手順を参照してください。
テン、典型的なサーバ構成
max_connectionsクライアント接続の最大数
table_open_cache表のファイルハンドルキャッシュ（テーブルデータは、ファイルを開くには、ディスクのファイルをキャッシュする扱いやすいデータを読み込み、ディスクに格納されています）
key_buffer_sizeインデックスのキャッシュサイズ（メモリへのディスクキャッシュから読み込まれたインデックスは、あなたがより大きく設定することができ、それがすぐに取り出せるを助長しています）
innodb_buffer_pool_size、Innodbストレージエンジンのキャッシュ・プールのサイズ（のためのInnodbすべてのテーブルが使用されている場合、最も重要な一つの構成、Innodb、そうであっても、物理メモリの80％に設定値を示唆し、Innodb索引など性能向上の多くはこれに依存しています）
innodb_file_per_table（innodb表では、データに格納された.ibd設定項目が設定されている場合、ファイルONに対応するリスト次いで、ibdそうでなければ、ファイルのすべてのinnodb共有表空間）
