MySQL5.6の基本構成詳細説明

この記事では主に MySQL5.6 の基本的な最適化構成を紹介し、MySQL5.6 で最適化する必要がある構成項目を詳細に説明し、最後に最適化の事例を示します。 MySQL 5.6 には、デフォルトのオプションが多数ありますが、以前のバージョンよりもはるかに少ないチューニング オプションがあります。この記事では、最適化する必要がある構成項目

1.innodb_buffer_pool_size

インデックス(データ+インデックス)をロードするために使用するメモリの量を指定するため、最も重要な最適化オプションです。専用の MySQL サーバーの場合は、範囲を指定することをお勧めします。たとえば、物理メモリの 50 ～ 80%。マシンの場合、キャッシュ プールは約 50 GB に設定する必要があります。この値を大きく設定すると、十分な空きメモリが残らないなどのリスクが生じる可能性があります。オペレーティング システムと、バイナリ ログ、InnoDB トランザクション ログ (transaction

ファイル システム キャッシュに依存する一部の MySQL サブシステム。 2.innodb_log_file_size
- デフォルト値は 48M です。書き込みスループットが高い場合は、この値を大きくする必要があります。バックグラウンド チェックポイント アクティビティが長期間にわたってスムーズに書き込まれるようにすることで、パフォーマンスが向上します。この値を 4G 未満に設定すると、ログ ファイルが大きくなるという欠点が生じることが非常に安全です。 time 必要な修復時間ですが、これは 5.5 および 5.6 で大幅に改善されました 3.innodb_flush_method - ハードウェア RAID ディスク

を使用している場合、これは O_DIRECT に設定する必要がある場合があります。 InnoDB バッファ プールを読み取ると、「二重バッファリング」効果を防ぐことができます。そうしないと、ファイル システム キャッシュと InnoDB キャッシュの間に 2 つのコピーが形成されます。 ハードウェア RAID コントローラを使用していない場合、または SAN ストレージを使用している場合、O_DIRECT が発生する可能性があります。 MySQL ユーザー マニュアルとバグ #54306 で詳細が説明されています。4.innodb_flush_neighbors

5.innodb_io_capacity および innodb_io_capacity_max - これらの設定は、InnoDB が実行する操作の数に影響します。ハードウェアのパフォーマンス (1 秒あたりに実行できる IO 操作の数など) をよく理解している場合は、アイドル状態のままにするのではなく、これらの関数を使用することをお勧めします。 : 特定のフライトの航空券が 1 枚も販売されていない場合は、後で悪天候が発生した場合に備えて、後のフライトの何人かにそのフライトに乗ってもらうことが良い戦略になる可能性があります。つまり、機会があるときにバックグラウンド操作が処理されます。後でリアルタイム操作が可能になるため、競合を減らすためです。 非常に簡単な計算があります。各ディスクが 1 秒あたり 200 回読み書きできる場合 (IOPS)、10 台のディスクを備えた RAID10 ディスク アレイの理論上の IOPS = (10) /2) * 200 = 1000。これが「非常に単純」であると言うのは、通常、RAID コントローラーが追加のマージを提供し、SSD ディスクの IOPS 容量を効果的に増加させることができるためです。これら 2 つの値を高く設定しすぎると、バックグラウンド操作によってフォアグラウンド タスクの IO 操作のパフォーマンスが妨げられることは絶対に避けるべきです。設定が高すぎると、InnoDB が保持する内部ロックによりパフォーマンスが低下します (私が理解している情報によると、これは MySQL5.6 で大幅に改善されました)

- デフォルト値は 1024 です。 mysql 5.6 で導入された新しいオプション。Mark Callaghan がいくつかの設定提案を提供しました。簡単に言えば、innodb_io_capacity 値を増やす場合は、innodb_lru_scan_ Depth も増やす必要があります。

- デフォルトでは、バイナリ ログはクラッシュ セーフではありませんが、前の記事で述べたように、これをお勧めします。この場合、sync_binlog=1、sync_relay_log=1、relay-log-info-repository=TABLE、master-info-repository=TABLE.

- デフォルトでは、古いログは 1 ～ 10 日に設定することをお勧めします。バックアップからの復元がはるかに高速になるためです。 -id
- マスター/スレーブ レプリケーション トポロジ内のすべてのサーバーには、一意のサーバー ID を設定する必要があります。

4.binlog_format=ROW - 行ベースのレプリケーションに変更しました。私は最近行ベースのレプリケーションについて別の記事を書きました。この記事では、リソースのロックを減らすことでパフォーマンスを向上させることができるため、行ベースのレプリケーションが気に入っている理由を説明しています。有効にする必要があります:transaction-isolation=READ-COMMITTED および innodb_autoinc_lock_mode = 2.

その他の設定 (その他)

1.timezone=GMT タイムゾーンを GMT に設定することを推奨するシステム管理者が増えています。グリニッジ標準時 (GMT)。最近ではほとんどすべてのビジネスがグローバルになっているため、これをローカル タイム ゾーンに設定するのは少し恣意的であるように思えます。 =utf8mb4_general_ci

character-set(character-set) を無視するように Skip-character-set-client-handshake を設定することもできます。 3.sql-mode

STRICT_TRANS_TABLES,ERROR_FOR_pISION_BY_ZERO,
 NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,
 NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,
 NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY.

5.max_connect_errors - Todd Farmer は次のように書きました: 「[この機能は] ブルート フォース アクセス攻撃に対する無意味な保護を提供します。」 実際、skip-name-resolve を設定すると、max_connect_errors は機能しません (前の段落を参照)。

通常、「二重構成」を回避できるように max_connect_errors=100000 を設定します。

- デフォルトの値は 151 です。多くのユーザーがより大きな値、主に 300 ～ 1000 に設定しているのを見てきました。
通常、これは避けられません。値は大きく設定されますが、少し不安になるのは、16 コアのマシンでは、IO ブロッキングの場合、接続実行能力が約 2 ～ 10 倍しかないことです

条件が許せば、この問題を解決するために、アプリケーション用に最適化されたデータベース接続プール (接続プール) を構成できます。多数の接続を開いて維持する もちろん、接続プールを使用しない (プールされていない) アプリケーションも、できるだけ早く接続を開いてタスクを実行し、閉じることも可能です。 5.5 (MySQL Community Edition と Enterprise Edition の間にはいくつかの違いがあります) では、スレッド プール プラグインを使用します。

結論


MySQL サーバーの構成は、

2. IO が 1 秒あたり 2000 IOPS に達すると仮定します)3. マスター/スレーブのレプリケーション (レプリケーション) が必要です4. 新しいアプリケーション (例: 非レガシー システム)

7. グローバル アプリケーションを特定のタイム ゾーンで固定したくない場合
8. プログラムの信頼性と安定性を確保したい場合。

構成は次のようになります。りー

以上がMySQL5.6の基本構成詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。