Mysql の高度な - データベース チューニング戦略 (1)

その他のデータベースチューニング戦略

1.データベースのチューニング対策

1.1 調整目標

• システムがより大きな負荷サービスを提供できるように、システム リソースをできるだけ節約します。(スループットの向上)
• 合理的な構造設計とパラメータ調整により、ユーザーの操作応答速度を向上させます。(より速い応答)
• システムのボトルネックを軽減し、MySQL データベースの全体的なパフォーマンスを向上させます。

1.2 チューニングの問題を特定する方法

• ユーザーの声（主なもの）
• ログ解析（メイン）
• サーバーリソースの使用状況の監視
• データベースの内部状態監視
• 他の

1.3 寸法とチューニング手順

ステップ 1: 適切な DBMS を選択する

ステップ 2: テーブル設計を最適化する

ステップ 3: 論理クエリを最適化する

ステップ 4: 物理クエリを最適化する

物理クエリの最適化とは、論理クエリの最適化を決定した後、物理最適化技術（インデックス作成など）を利用し、コストモデルを計算して考えられるさまざまなアクセスパスを見積もり、実行プランの中で最もコストが低い実行プランを見つけることです。方法。

ステップ 5: Redis または Memcached をキャッシュとして使用する

データはデータベースに保存されているため、ビジネス ロジックの操作のためにデータベース層からデータを取得してメモリに配置する必要があり、ユーザー数が増加すると、頻繁なデータ クエリによってデータベース リソースが大量に消費されます。よく使用されるデータをメモリに直接配置すると、クエリの効率が大幅に向上します。

Key-Value ストレージ データベースは、この問題の解決に役立ちます。
一般的に使用されるキーと値のストレージ データベースには Redis と Memcached があり、どちらもデータをメモリに保存できます。

ステップ 6: ライブラリレベルの最適化

1. 読み書きの分離

2. データの断片化

2. MySQLサーバーを最適化する

2.1 サーバーハードウェアの最適化

サーバーのハードウェア パフォーマンスは、MySQL データベースのパフォーマンスを直接決定します。ハードウェアのパフォーマンスのボトルネックは、MySQL データベースの実行速度と効率を直接決定します。パフォーマンスのボトルネックに対するハードウェア構成を改善すると、MySQL データベースのクエリと更新の速度が向上します。(1) より大きなメモリを構成する (2) 高速なディスクシステムを構成する (3) ディスク I/O を合理的に分散する (4) マルチプロセッサを構成する

2.2 MySQL パラメータの最適化

• innodb_buffer_pool_size : このパラメータは、Mysql データベースの最も重要なパラメータの 1 つで、InnoDB タイプのテーブルとインデックスの最大キャッシュを示します。インデックス データだけでなく、テーブル データもキャッシュします。この値が大きいほど、クエリが高速になります。ただし、この値が大きすぎると、オペレーティング システムのパフォーマンスに影響します。

• key_buffer_size ：インデックスバッファのサイズを示します。インデックス バッファはすべてのスレッドで共有されます。インデックス バッファを増やすと、(すべての読み取りと複数の書き込みに対して) インデックスの処理が向上します。もちろん、値が大きいほど良いのですが、そのサイズはメモリのサイズに依存します。この値が大きすぎると、オペレーティング システムが頻繁にページを変更し、システムのパフォーマンスが低下します。約 4GB のメモリを備えたサーバーの場合、このパラメータは 256M または 384M に設定できます。

• table_cache : 同時にオープンされるテーブルの数を示します。この値が大きいほど、同時に開くことができるテーブルの数が増えます。物理メモリが大きいほど、設定も大きくなります。デフォルトは 2402 ですが、512 ～ 1024 に調整するのが最善です。同時に開かれるテーブルが多すぎるとオペレーティング システムのパフォーマンスに影響を与えるため、この値はできるだけ大きくしません。

• query_cache_size : クエリバッファのサイズを示します。これは MySQL コンソールで確認できます。Qcache_lowmem_prunes の値が非常に大きい場合は、バッファリングが不十分であることが多いため、Query_cache_size の値を増やす必要があることを示します。Qcache_hits の値が非常に大きい場合は、クエリ バッファは非常に頻繁に使用されます。値が小さい場合は効率に影響するため、キャッシュをクエリしないことを検討できます。値が非常に大きい場合は、Qcache_free_blocks が多数あることを示します。バッファ内のフラグメント。MySQL8.0以降は無効です。このパラメータは、query_cache_type と組み合わせて使用​​する必要があります。

• query_cache_type 値が 0 の場合、すべてのクエリはクエリ キャッシュを使用しません。ただし、query_cache_type=0 を指定しても、MySQL は query_cache_size で設定されたキャッシュ メモリを解放しません。

  • =1の場合query_cache_type、クエリ ステートメントで SQL_NO_CACHE が指定されていない限り (SELECT SQL_NO_CACHE * FROM tbl_name など)、すべてのクエリでクエリ キャッシュが使用されます。
  • =2の場合query_cache_type、クエリ ステートメントで SQL_CACHE キーワードが使用されている場合にのみ、クエリはクエリ キャッシュを使用します。クエリ キャッシュを使用すると、クエリの速度が向上します。この方法は、変更操作がほとんどなく、同じクエリ操作が頻繁に実行される状況にのみ適しています。

• sort_buffer_size : ソートが必要な各スレッドによって割り当てられるバッファのサイズを示します。このパラメータの値を増やすと、ORDER BY または GROUP BY 操作の速度が向上します。デフォルト値は 2 097 144 バイト (約 2MB) です。約 4GB のメモリを搭載したサーバーの場合、推奨設定は 6 ～ 8M で、接続数が 100 の場合、割り当てられるソート バッファの合計サイズは 100 × 6 = 600MB になります。

• join_buffer_size = 8M: 結合クエリ操作に使用できるバッファ サイズを示します。sort_buffer_size と同様に、このパラメータに対応する割り当てメモリも各接続に排他的です。

• read_buffer_size ：連続スキャン時に各スレッドがスキャンする各テーブルに割り当てられるバッファのサイズ（バイト単位）を示します。このバッファは、スレッドがテーブルからレコードを連続的に読み取る場合に必要です。SET SESSION read_buffer_size=n は、このパラメータの値を一時的に設定できます。デフォルトは 64K ですが、4M に設定できます

• innodb_flush_log_at_trx_commit : バッファ データがログ ファイルに書き込まれ、ログ ファイルがディスクに書き込まれる時期を示します。このパラメータは innoDB エンジンにとって非常に重要です。このパラメータには 0、1、2 の 3 つの値があります。このパラメータのデフォルト値は 1 です。

• 値 1 は、トランザクションがコミットされるたびにデータがログ ファイルに書き込まれ、ログ ファイルが同期のためにディスクに書き込まれることを意味します。このモードは最も安全ですが、最も遅くなります。なぜなら、トランザクションの送信やトランザクション外の命令では、ログをハードディスクに書き込む (フラッシュする) 必要があるからです。

• 値が 2 の場合、トランザクションがコミットされるたびにデータがログ ファイルに書き込まれ、ログ ファイルが 1 秒ごとにディスクに書き込まれることを意味します。このモードは 0 よりも高速かつ安全です。オペレーティング システムがクラッシュするかシステムの電源がオフになった場合にのみ、直前の 1 秒間のすべてのトランザクション データが失われる可能性があります。

• innodb_log_buffer_size : これは、InnoDB ストレージ エンジンのトランザクション ログによって使用されるバッファです。パフォーマンスを向上させるために、情報は最初に Innodb ログ バッファにも書き込まれます。innodb_flush_log_trx_commit パラメータで設定された対応する条件が満たされると (またはログ バッファがいっぱいになると)、ログはファイルに書き込まれます (またはログ バッファに同期されます)。ディスク）。

• max_connections : MySQL データベースに許可される最大接続数を示します。デフォルト値は 151 です。ステータス変数 connection_errors_max_connections がゼロではなく、増加し続ける場合は、データベース接続数が最大許容値に達したため、接続リクエストが失敗し続けていることを意味します。この場合、max_connections の値を増やすことを検討できます。Linux プラットフォームでは、500 ～ 1000 の接続をサポートするのは、パフォーマンスの良いサーバーであれば難しくありませんが、サーバーのパフォーマンスに基づいて評価し、設定する必要があります。これらの接続はメモリ リソースを浪費するため、接続数は多いほど良いです。接続が多すぎると、MySQL サーバーがフリーズする可能性があります

• back_log : MySQL が TCP ポートをリッスンするときに設定されるバックログ リクエストのスタック サイズを制御するために使用されます。MySql 接続数が max_connections に達すると、新しいリクエストはスタックに保存され、特定の接続がリソースを解放するのを待ちます。スタックの数は back_log です。待機中の接続数が back_log を超えると、接続リソースは付与されません. エラーが報告されます。バージョン 5.6.6 より前のデフォルト値は 50 で、それ以降のバージョンのデフォルト値は 50 + (max_connections / 5) です。Linux システムの場合は、512 未満の整数に設定することをお勧めしますが、最大値は超えません900。データベースが短期間に大量の接続要求を処理する必要がある場合は、back_log の値を適切に増やすことを検討できます。

• thread_cache_size : スレッド プール内のキャッシュされたスレッドの数のサイズ。クライアントが切断されると、現在のスレッドがキャッシュされます。新しい接続要求を受信すると、新しいスレッドを作成せずに応答が速くなります。これにより、特に短い接続を使用するアプリケーションの場合、接続作成の効率が大幅に向上します。パフォーマンスを向上させるために、このパラメータの値を増やすことができます。デフォルトは 60 ですが、120 に設定できます。

スレッド プールのサイズは、次の MySQL ステータス値によって適切に調整できます。

mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 2 |
| Threads_connected | 1 |
| Threads_created | 3 |
| Threads_running | 2 |
+-------------------+-------+
4 rows in set (0.01 sec)

Threads_cached がどんどん少なくなっても、Threads_connected が減らず、Threads_created が増加し続ける場合、thread_cache_size のサイズを適切に増やすことができます。

• wait_timeout: リクエストの最大接続時間を指定します。約 4GB のメモリを備えたサーバーの場合、5 ～ 10 に設定できます。
• interactive_timeout: 接続を閉じる前にサーバーがアクションを待機する秒数を示します。

my.cnf の参照構成は次のとおりです。

[mysqld]
port = 3306 serverid = 1 socket = /tmp/mysql.sock skip-locking #避免MySQL的外部锁定，减少
出错几率增强稳定性。 
skip-name-resolve #禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权要使用IP地址方式，否则MySQL将无法正常处理连接请求！ 
back_log = 384
key_buffer_size = 256M
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
read_buffer_size = 4M
read_rnd_buffer_size=16M
join_buffer_size = 8M
myisam_sort_buffer_size =64M 
table_cache = 512 
thread_cache_size = 64 
query_cache_size = 64M
tmp_table_size = 256M
max_connections = 768 
max_connect_errors = 10000000
wait_timeout = 10 
thread_concurrency = 8 #该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8 
skipnetworking #开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！ 
table_cache=1024
innodb_additional_mem_pool_size=4M #默认为2M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=2M #默认为1M
innodb_thread_concurrency=8 #你的服务器CPU有几个就设置为几。建议用默认一般为8
tmp_table_size=64M #默认为16M，调到64-256最挂
thread_cache_size=120
query_cache_size=32M

2.3 事例分析

電子商取引プラットフォームにはデータが多すぎて CPU 使用率が高すぎるため、データベースを調整する必要があります。

システムパラメータ InnoDB_flush_log_at_trx_commit を調整します。

デフォルト値は 1 です。2 に変更します。トランザクションが送信されるたびにディスクの読み取りと書き込みを開始する必要はありません。大規模な同時実行シナリオでは、システム効率が向上し、CPU 使用率が削減されます。

システムパラメータ InnoDB_buffer_pool_size を調整する

InnoDB ストレージ エンジンが使用されます缓存来存储索引和数据。値が大きいほど、キャッシュ領域にロードできるインデックスとデータが多くなり、必要なディスクの読み取りと書き込みの回数が減ります。パラメーターを 64G に変更すると、ディスクの読み取りと書き込みの回数が大幅に削減されます。メモリを最大限に活用し、CPU リソースの一部を解放できます。

システムパラメータ InnoDB_buffer_pool_instances を調整します。

并行处理能力複数のプロセスがキャッシュの異なる部分を同時に処理できるようにすることで、システムのパフォーマンスを向上させることができます。

CPUリソース不足の問題が発生した場合の2つのアイデア

• 道路の渋滞箇所を解消し、ボトルネックを解消し、待ち時間を短縮します。
• 新しいチャネルを開拓し、並列処理能力を向上させます