アウトライン

序文

A MySQLのボトルネックと対策

2つの特定のMySQLの最適化パラメータ

三MySQLの最適化の実践

四つの概要

リファレンス

序文

1まず、パフォーマンスのボトルネックがショーを指揮探し

我々は、コマンドを示しMySQLと変数の状態を表示するシステムのボトルネックを見つけることができます。

MySQLの>ショーのステータス - 表示状態情報（「XXX」のような拡張されたショーのステータス）

MySQLの>ショー変数 - システム変数（「XXX」のような拡張されたショーの変数）

MySQLは> InnoDBのステータスを表示 - ディスプレイInnoDBストレージエンジンの状態を

MySQLの>ショーPROCESSLIST - 例えば、ロックテーブルかどうかのように、状態の実装を含む、現在のSQL実装を表示します

シェル> mysqladminは変数-uユーザ名-p password--システム変数

シェル> mysqladminのは、-uユーザ名-p password--表示ステータス情報ステータスを拡張しました

状態変数とヘルプを表示します。

シェル>のmysqld -verbose -help

スロークエリログをオンにし、それらの遅いSQLを見つけます

実際には3、最良の方法は、上司が遅い応答を最適化する必要が受け入れることができない感じています。

A MySQLのボトルネックと対策

MySQLはボトルネックです。単一のテーブルのMySQLのデータ量を超える千万レベルに達した場合、MySQLの最適化のいずれかの場合には、どのように単純なクエリ、MySQLのパフォーマンスが大幅に削減されます。対策：

1）サーバのCPUとメモリサイズの数を増やすことは、MySQL構成バッファ及びキャッシュの値を増やし、これは主にMySQLのパフォーマンスのボトルネックに対処します。
パフォーマンスの最適化、最も重要な効果は、間違いなく最も低コストのハードウェアおよびサーバー最適化したので、これが最初に検討する必要があります。
2）サードパーティのエンジンまたは派生バージョンを使用。
大幅に改善されているMySQLのよりも機能や性能でPerconaとして、InnoDBエンジンに無料MariaDB性能のMySQLの創設者によって開発されたのMySQLよりも優れている。
公式サイトによると、数で、他の改善された製品TokuDBは、MySQLのパフォーマンス10倍以上。これらの誘導体バージョンやMySQLの修正版は、MySQLのInnoDBのために主に
エンジン。InnoDBのデータ（耐久）ディスクに永続化されていることを確実にするために、物事の各提出は、あなたがかつて語ったのfsyncファイルシステムを呼び出す必要がある場合は、キャッシュ内のデータができる
時代にフラッシュ、ああを押します。fsyncを操作自体は、毎回の事はfsyncを別の操作を提出しない場合、これは、（より多くのI / Oリソース、遅い応答を消費する）で非常に「高価」である
ので、そこに、TPSのシステムのボトルネックになります当社グループは、コンセプトをコミットします。MySQLの5.0の後、分散アーキテクチャを考慮して、内部InnoDBがコミットすることを確実にするために
順序をとMySQLが一貫したログに記録し、InnoDBはサポートグループがコミット放棄することを余儀なくされました。その後、それは良い解決されていません。MariaDBの表示されるまでにかなりの完璧なソリューションです
。この問題。
3）他のデータベースに移行します。
オープンソースと商用加熱SQL Oracleなどのポスト。OracleとPostgreSQLのと比較すると、MySQLはスレッドモデルに属し、およびプラグインエンジンのアーキテクチャを採用しています。この実装は
、軽量かつ高速、システムリソース、サポートより多くの同時接続が、プロセスモデルの小さな消費がより完全にCPUリソースを使用することができ、複雑なビジネスクエリを扱うことの利点：独自の利点を持っています。例えば、
従来の最適化は、Oracleの前提の下ではなく、MySQLのよりはるかに優れ、2億のレベルのデータの量で、パフォーマンスのボトルネックを経験しません。また、リレーショナルクエリおよび組み込みの関数や他の関数では、
OracleデータベースはMySQLの勝利です。PostgreSQLデータベースは、MySQLと比較する別の例として、より強力なクエリオプティマイザは、頻繁にマテリアライズド・ビューおよびその他のサポートインデックスを再構築しませんしている
利点を。もちろん、他のデータベースに移行するには、そのようなOLTPのバイアスされたアプリケーション（オンライン・トランザクション処理、オンライン・トランザクション処理）やバイアスとして、アプリケーションの種類に依存
OLAP（オンライン分析処理、オンライン分析処理）アプリケーション。
4）単一テーブルの量を低減するために、データベース、サブテーブルを仕切ります。
そのようなMemcachedの、Redisのような5）使用のNoSQL他の補助溶液。
6）データ分割と分散展開のために使用ミドルウェア、この領域における典型的なケースは、オープンソース・ミドルウェアアリババ外国コバーのデータベースを持っています。
7）データベース接続プール。
3:00で、我々は言っている、MySQLはより多くの同時接続をサポートできる、スレッドモデルです。MySQLはOracleとPostgreSQLの接続よりも多くをサポートすることができます。だから、オラクル
そして、PostgreSQLのアプリケーションは、通常、接続、データベース接続プールを多重化します。では、なぜこれらの共通のデータベース接続プールの技術のMySQLデータベースアプリケーションを使用する必要がありますか？その理由は、ということである
MySQLのメカニズムはまだ完全ではありませんが、プログラム内の問題のいくつかは、リードMySQLデータベース接続ブロックする可能性があり、大規模な同時の場合には、それは多くのリソースと繰り返し接続された接続無駄になる
消費を。ある程度高い同時接続の圧力を緩和することができ、接続がキューイングおよび多重ように、データベース接続プールを使用します。
同社の技術力は、MySQLの二次開発と改善のために十分であるので、これは持っている一方で、ある、MySQLのボトルネックは本当ですが、多くの大規模なインターネット企業は、まだMySQLを使用しており、同様に使用することができますその洗練されたアーキテクチャの恩恵を受ける。だから、良いツールを使用することができない、人的要因が大きな割合を占めています。

2つの特定のMySQLの最適化の実践

以下の最初のユニバーサルギガビットGBとの違い

GB 0.1342（ギガバイト）
1.074ギガビット（ギガビット）
のメモリは、一般的にGB、GBだけを言うことはありません。
ここでは、実際には、有名なグランドBとBの差が小さいです。
一般的に、ニュースレターは言う、それは、少し小さなbが、ある、平均ビット。
バイトは、バイトと呼ばれ、8ビットで大きなB.です
私たちは、一般的に言って、ブロードバンド、4M、4Mビットで、8に加えて、コンピュータBの一般的な使用で、ダウンロード速度は400キロバイト程度です。
メモリー容量はGbは、帯域幅はGbの関与になると言っていません。
基本的には、Bは、伝送レートをコンセプトに関係するだろうです。

サイズ測定容量GB、GBのサイズ伝送レートの通信がまとめました。

1 TRANSACTION_ISOLATION

解釈：MySQLのデフォルトは独自のギャップロックが解決使用REPEATABLE-READ、ある一方、トランザクション分離レベルは、Oracle、SQL Serverと、よく知られているデフォルトレベルの他の商用データベースは、READ-COMMITTEDである「ファントム読み取りを。」しかし、また、READ-COMMITTEDレベルのレコードロックに比べてギャップロックのため、ため、REPEATABLE-READトランザクション同時挿入のパフォーマンスが大幅に制限されています。
設定：財務ない、電気通信および業務執行の他の高レベルの要件は、TRANSACTION_ISOLATION = READ-COMMITTEDを設定することができれば分離レベルを選択することは、実際のビジネス要件（安全性と性能のトレードオフ）に依存します。

2 innodb_buffer_pool_size

解釈：InnoDBはMySQLがメモリにキャッシュすることができますどのくらいのデータとインデックスを決定するプールのサイズを、バッファが、常にディスクから読み取れません。Redisのは非常に高速読み込みと書き込み、最も重要な理由は、それがメモリ内にキャッシュされているすべてのデータだということであると私たちは皆知っています。innodb_buffer_pool_size十分に大きい場合を想像MySQLのすべてのテーブルとインデックスのデータをキャッシュすることができ、それは一種どんな経験のでしょうか？
設定：あなたは、専用のMySQLサーバの場合は、通常のオペレーティング・システム・メモリの約75％に設定されますが、少なくとも、メモリの2Gは、オペレーティング・システムの保守およびMySQLの例外処理のために予約しました。

3 innodb_buffer_pool_instances

解釈：InnoDBはインスタンスのプール番号をバッファ、InnoDBのバッファプールは、高並列トランザクションの下で、起因ミューテックス（保護されたページのリスト）の存在下に全リンクリストページ（セグメントクラスター、P）によって管理されています競争と待機をロックする必要性についてのページを読み取りおよび書き込み。innodb_buffer_pool_instancesを提供することによって、リスト全体は、これにより効率を向上させる、各プールインスタンス管理ページおよびそれらの相互に排他的な、複数に分割されています。
セット：プール（上記8G）が比較的大きい場合、バッファプール（32G以上）は、2〜3世代のインスタンスごとに分割することができる場合は特に、innodb_buffer_pool_size / innodb_buffer_pool_instances = 1Gに応じて設定することができ、インスタンスのより数はありませんよく、マルチインスタンス・マルチスレッド、スレッドのオーバーヘッド（CPU、MEM）の代わりに考慮されなければなりません。

4 innodb_log_file_size

解釈：InnoDBのログファイルのサイズ（REDOログ）、InnoDBテーブルに保存されたレコードを変更するために重要、でib_logfile1をib_logfile0。大きいinnodb_log_file_size、ダーティ・データ・バッファ・プール・チェックポイントは、それによって高い同時によって生じるピーク荷重を低減するために、ディスクIOを低減、周波数少ないブラシ板に（チェックポイント）が必要です。データベースの再起動innodb_log_fileからのデータ読み出しは、長い回復時間を実行したときに、メモリ内のダーティデータは、異常なデータベースのクラッシュ後、ブラシプレートの頻度を低減するので、ログファイルは、大きな約束ではありません。

提供：次のように一般的には、標準で1時間のログトラフィックのピークの量を選択し、計算されます。

＃コマンド
のMySQL-uroot - h172.26.96.146 -p -e 'ショーエンジンInnoDBのステータス\ G' | grepを'ログシーケンスナンバー' \
&& SLEEP 60 \
&&のMySQL-uroot - h172.26.96.146 -p -e "表示エンジンInnoDBのステータス\ G |ログ・シーケンス番号' 'のgrep'
の＃出力
ログシーケンス番号149 949 388 055
ログシーケンス番号149 959 622 102

＃が計算される
（ - 149 949 388 055 149 959 622 102）/ 1024分の1024 = 10Mの
10/60 * 3600 = 600M
2分の600 = 300M

＃辞書
書き込み動作のログ・シーケンス番号を表すログのバイトのこれまでのInnoDB総数、2つの印刷睡眠60秒の間、スレッド
1分10M内のトランザクション・ログ・レコードの合計量を与えるためには、時間、合計600Mに変換
`ためib_logfile0、ファイル、300M用のファイルの書き込みに2サイクルをib_logfile1`
最終的に、innodb_log_file_size = 300M

5 innodb_flush_log_at_trx_commit

解釈：InnoDBはトランザクションログ機会ブラシプレート

0、トランザクションがコミットは、バッファをログに記録するときは、バックグラウンドスレッドは、システムログバッファに書き込まれたバッファの毎秒を書く、書かれている実際の物理的なログファイルのタイミングは、オペレーティング・システムによって異なります。

1、トランザクションがコミットは、バッファをログに記録するときは、マスタースレッドの同期が完全に標準のInnoDB ACIDトランザクションに沿ったものである直接物理ログバッファのログファイルに書き込まれます、データが失われることはありません。

2、トランザクションがシステムバッファに提出すると、マスターは物理ログに書き込まれた毎秒のバッファのシステムログファイルを通します。
セキュリティ1> 2> 0、速度0> 2> 1、ビジネスの実際のニーズに応じて（安全性と速度のトレードオフ）を選択ブラシディスク妥当な時間。

6もしinnodb_file_per_table

解釈：InnoDBの別の表領域、innodb_file_per_tableを=はON、データとインデックスを記憶するための別個の物理ファイル（の.ibd）内のすべてのテーブルが、すなわち物理ファイル（ibdata1と）空間テーブルを共有していることをinnodb_file_per_tableを= OFF手段を各テーブルを表します。ドロップ/切り捨てテーブル運転による場合、物理ストレージは、別の表スペースになり共有表スペースが回収されないとだけ増加されていたであろうしながら直ちに、（削除/初期化）が回収されます。
提供される：もしinnodb_file_per_table = ON、それは別のテーブルとインデックススペースことに留意すべきである、そのようなログ・バッファ（アンドゥログ）圧延としてのみデータを格納、索引バッファ（挿入バッファ）を挿入し、第2の書き込みバッファ（二重書き込みバッファ）などの放電共有テーブルスペースインチ

query_cache_sizeの
解釈：クエリキャッシュのサイズ、それはとても構文解析、最適化、実行ステージ、バッファプール内の直接の戻りデータをスキップし、クエリを押す前に、変更されません。このクエリをデータテーブルを追跡するためにあります。（データベース内のデータの周波数の小さな変化があれば）、データがキャッシュ無効化以降に変更された後、実際のOLTPシステムでは、クエリキャッシュはほとんどヒットしません。クエリキャッシュは、テーブル内のすべての変更を追跡しますので、それはデータベース全体（リソースの競合ポイント）のボトルネックになります。
設定する：query_cache_size = 0、セットquery_cache_type = 0と連携して、MySQL5.7.20は、上記、MySQL8.0は、すべての直接クエリキャッシュの設定項目を放棄します。

MAX_CONNECTIONSの
解釈：接続の最大数、小さすぎるのmax_connections（デフォルト151）を設定すると、MySQLはエラーが多すぎ接続することがあります。MAX_CONNECTIONSは（1,000以上）が大きすぎる設定されている場合、オペレーティングシステムはスレッドと応答しない間ビジー切り替えてもよいです。
提供される次のように各接続は、いくつかのメモリを消費する、計算されます。

三つは、MySQL 5.7パフォーマンスの最適化の戦闘を言うようになりました

彼らは、MySQL5.7で今、直接動的な設定、利便性の多くを有効になる前にmysqlのプロセスを再起動する必要がありますInnodb_Buffer_Pool_sizeサイズを調整します。

この関数は、アプリケーションのシナリオ：

大量のデータのすべてのデータのクエリ、チューニングする必要があります。
メモリを増やすためにBマシン、DBAはInnodb_Buffer_Pool_sizeを上げることを忘れ不注意。
DBAに新しい仕事のC転送は、Innodb_Buffer_Pool_size不合理元DBAの設定を見つけました。

地元の関心のニーズは、調整が完了するまで、調整BUFFER_POOL時に、ユーザの要求がブロックされますので、朝3-4の低ピーク点を調整し、日中調整しないでください。

調整したとき、内部データ・ページは、ブロック単位で、新しい場所に移動されます。あなたは、パラメータの大きさを調整するinnodb_buffer_pool_chunk_size必要性を移動速度を上げたい場合は、デフォルト値は128Mです。

例（BP 128M 384Mの増加）：

MySQLの> SELECT @@ innodb_buffer_pool_size。

+ --------------------------- +

| @@ innodb_buffer_pool_size |

+ --------------------------- +

| 134217728 |

+ --------------------------- +

セット内の1行（0.00秒）

MySQLの> SELECT @@ innodb_buffer_pool_chunk_size。

+ --------------------------------- +

| @@ innodb_buffer_pool_chunk_size |

+ --------------------------------- +

| 134217728 |

+ --------------------------------- +

セット内の1行（0.00秒）

MySQLの> SET GLOBALのinnodb_buffer_pool_size = 402653184;

クエリOK、影響を受けた0行（0.01秒）

MySQLの> SELECT @@ innodb_buffer_pool_size。

+ --------------------------- +

| @@ innodb_buffer_pool_size |

+ --------------------------- +

| 402653184 |

+ --------------------------- +

セット内の1行（0.00秒）

innodb_buffer_pool_chunk_sizeサイズはinnodb_buffer_pool_size / innodb_buffer_pool_instances計算されます

例えば、今、2G innodb_buffer_pool_size初期化さinnodb_buffer_pool_chunk_size自動的innodb_buffer_pool_chunk_size 1G 512M、例調整、1Gに設定innodb_buffer_pool_instances例4：
。./mysqld --innodb_buffer_pool_size = 2147483648 = --innodb_buffer_pool_instances 4
--innodb_buffer_pool_chunk_size = 1073741824。

MySQLの> SELECT @@ innodb_buffer_pool_size。

+ --------------------------- +

| @@ innodb_buffer_pool_size |

+ --------------------------- +

| 2147483648 |

+ --------------------------- +

セット内の1行（0.00秒）

MySQLの> SELECT @@ innodb_buffer_pool_instances。

+ -------------------------------- +

| @@ innodb_buffer_pool_instances |

+ -------------------------------- +

| 4 |

+ -------------------------------- +

セット内の1行（0.00秒）

＃チャンクサイズは、起動時に1ギガバイト（1073741824バイト）に設定したがありました

＃innodb_buffer_pool_size / innodb_buffer_pool_instancesに切り捨て

MySQLの> SELECT @@ innodb_buffer_pool_chunk_size。

+ --------------------------------- +

| @@ innodb_buffer_pool_chunk_size |

+ --------------------------------- +

| 536870912 |

+ --------------------------------- +

セット内の1行（0.00秒）

バッファー・プール調整プロセスの監視

変数名= 'InnoDB_buffer_pool_resize_status' のmysql> SHOWのSTATUS;

+ ---------------------------------- + -------------- -------------------- +

| 変数名| バリュー|

+ ---------------------------------- + -------------- -------------------- +

| Innodb_buffer_pool_resize_status | また、他のハッシュテーブルのサイズを変更します。|

+ ---------------------------------- + -------------- -------------------- +

セット内の1行（0.00秒）

アラームxing'i表示するには、コマンドに続いて
のMySQL>ショー表し警告を、
+ --------- + ------ + -------------------- + ----------------------------------------------
|レベル|コード|メッセージ|
+ --------- + ------ + ---------------------------- + --------------------------------------
'：ここが間違っinnodb_buffer_pool_size値で切り捨て| |警告| 1292 1073741824「|
+ --------- + ------ + ----------------------------- + -------------------------------------
SET（0.00秒）に1行が

警告登場実際のサイズを見て

のMySQL>の表示変数LIKE '%% innodb_buffer_pool_size';
+ -------- + ------------------------- + -----
|変数名|価値|
+ ------------------------- + ------------ - +
| innodb_buffer_pool_size | 1073741824 |
+ ------------------------- + ------------- +
セットにおける1行（0.00秒）