my.cnf (my.ini) 重要なパラメータの最適化設定手順

my.cnf (my.ini) 重要なパラメータの最適化設定手順

MyISAM ストレージエンジン

MyISAM ストレージ エンジンは、書き込みよりも読み取りが多く、読み取りパフォーマンスに対する要件が高いシステムに適しています。

公式ドキュメント: http://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html

Key_buffer_size はメモリの約 30% ~ 40% に設定できます。 '%key_buffer_size%' のような変数を表示することで、

'%key_blocks_unused%' のような show global status で残っているかどうかを確認します。残っている量が多い場合は、key_buffer_size を増やす必要はありません。MyISAM を使用しない場合は、16m から 32m に設定することをお勧めします。

Query_cache アプリケーションに大量の読み取りがあり、アプリケーション レベルでキャッシュがない場合は、これを設定すると便利ですが、あまり大きく設定しないでください。メンテナンスのオーバーヘッドが高くなり、MySQL が遅くなります。32m から 512m が推奨されます。

Sort_buffer_sizeは複雑なクエリを実行するときに使用され、8mから16mが推奨されます。

Query_cache_size は、選択されたクエリの結果をキャッシュします。同一クエリが多数ある場合は、この値を増やすことができます。

Bulk_insert_buffer_size はバッチ挿入に使用され、key_buffer_size より小さくする必要があります。

Read_rnd_buffer_size は、SQL に order by があり、2 番目のクエリが実行される場合に使用されます。ソートを記録し、メモリから直接読み取ります。

Thread_cache_size は、再利用のためにキャッシュに保持されるスレッドの数を指定します。値が設定値内であれば、スレッドは切断されても破棄されず、新しい接続を待機します。スレッド作成のオーバーヘッドを削減します。

パラメータ公式リファレンスドキュメント: http://dev.mysql.com/doc/refman/5.6/en/optimizing-myisam.html

Innodb ストレージ エンジン

Innodb ストレージ エンジン1

同時実行スレッド数: Innodb_thread_concurrency=0 [デフォルト] は同時実行がないことを意味するのではなく、同時実行チェックなしで無制限の同時実行を意味します。 InnoDBは内部的に0から1000までの値を制御します

提案:

CPU 数 + ディスク数 * 2。RAID マスタースレーブシステムの場合は、バックアップディスクがあるため 2 を掛けないでください。

Innodb ストレージ エンジン 2

Innodb_io_capacity のデフォルト値は 200 です。これは、ディスク IO のスループット、つまり、innodb バックグラウンド プロセスが 1 秒あたりに IO 操作を処理できるデータ ページ数の上限を表していると思います。

Innodb_io_capacity_maxのデフォルトは2000です。IO制限を設定します。

ソースコード: innodb ストレージ エンジン レイヤー (主に srv0srv.c ファイル) で srv_io_capacity を検索します。

SSD を使用する場合は、ディスク IO スループットを満たすまでさらに増やすことができます。

Innodb ストレージ エンジン 3

innodb_max_dirty_pages_pct innodb バッファから innodb によって更新されるダーティ ページの比率 15% - 80%

ソースコード: innodb ストレージ エンジン レイヤー (主に srv0srv.c ファイル) で srv_max_buf_pool_modified_pct を検索します。

Innodb ストレージ エンジン 4 [重要]

innodb_flush_method (O_DSYNC、O_DIRECT) は、

O_DSYNC: InnoDB は、ログ ファイルを開いたり更新したりするために O_SYNC モードを使用し、データ ファイルを更新するために fsync() 関数を使用します。

O_DIRECT: InnoDB は O_DIRECT モードを使用してデータ ファイルを開き、fsync() 関数を使用してログとデータ ファイルを更新します。

RAID デバイスでは、innodb_buffer と raid によってデータが複数回キャッシュされるのを防ぐために、O_DIRECT モードに設定します。つまり、ログ ファイルを開かずにデータ ファイルを直接開きます。

ソースコード: innodb ストレージ エンジン レイヤーで srv_unix_file_flush_method を検索します (主に log0log.c および os0file.c ファイル内)

Innodb ストレージ エンジン 5 [重要]

innodb_バッファプールサイズ

Innodb は lru に従い、データを入力するときのデータ状況に基づいて innodb_buffer_pool_size にデータをロードします。データを操作するとき、データファイル内を検索する必要がなく、メモリから直接見つけることができます。

一般的にはメモリの80%程度に設定されますが、データファイルの総量を考慮する必要があります。 Buffer_pool_size + データが占有する容量 + オペレーティング システムによって使用されるメモリ = メモリ サイズ。できるだけ多く設置してください。

ソース コード: innodb ストレージ エンジン レイヤー (srv0srv.c および srv0start.c ファイル内) で srv_buf_pool_size を検索します。

Innodb ストレージ エンジン6

複数のインスタンスがある場合は、innodb_buffer_pool_instances を設定する必要があります。

ソースコード: innodb ストレージ エンジン レイヤー (主に buf0buf.c ファイル) で srv_buf_pool_instances を検索します。

Innodb ストレージ エンジン7

innodb_log_file_size ログファイルのサイズ

innodb_log_buffer_size ログキャッシュサイズ

まず innodb_log_buffer に書き込みます。バッファがいっぱいになるか、トランザクションがコミットされると、データを更新します。大規模なトランザクションが頻繁に発生する場合は、innodb_log_buffer_size を増やします。デフォルトは 16M です。

ソースコード: innodb ストレージ エンジン レイヤー (主に log0log.c ファイル) で srv_log_buffer_size を検索します。

Innodb ストレージ エンジン 8 [重要]

テーブルごとの Innodb ファイル

Innodb_file_per_table が 1 に設定されている場合、これはオンになり、すべてのテーブルが独立した表領域に設定され、テーブルごとに 1 つのデータ ファイルが作成されます。また設定

Innodb_open_files (同時に開いているファイルの数)。各テーブルはデータ ファイルに対応しているため、複数のテーブルを照会できるように、同時に開くことができるファイルの数を設定する必要があります。また、テーブルを別のディスクに移動する場合、すべてのテーブルが共有テーブル スペースを使用しているため、共有テーブル スペースを移行することはできません。

デフォルトでは、すべてのテーブルは共有スペースに配置されます。それはオフです

InnoDB ストレージ エンジン 9

Innodb_flush_log_at_trx_commit コアパラメータ:

0: ログバッファの内容をトランザクションログに書き込み、1秒ごとにディスクにフラッシュします。

1: 各トランザクションがコミットされると、ログバッファの内容がトランザクションログに書き込まれ、データディスクに書き込まれます。

2: 各トランザクションがコミットされ、ログバッファの内容がトランザクションログに書き込まれますが、データはディスクにフラッシュされません。

同期_binlog

二重一貫性モード: innodb_flush_log_at_trx_commit=1;sync_binlog=1; この方法では、マスターとスレーブのデータの一貫性が保たれ、データが失われることはありません。

公式パラメータ説明アドレス: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html

システムパラメータの最適化

NUMA (デュアルインスタンスでは、各インスタンスをNUMAのみで制御されるノードの下に配置できます)

OS レイヤーで NUMA が無効になっている場合、BIOS レイヤーで NUMA を有効にするとパフォーマンスに影響し、QPS が約 15 ~ 30% 低下します。

BIOS レベルで NUMA がオフになっている場合、OS レベルで NUMA がオンになっているかどうかに関係なく、パフォーマンスは影響を受けません。

システム最適化 jemalloc

ネットワーク カードの最適化: RPS+RFS

メモリ割り当て

1) jemallocソースパッケージをダウンロードする
http://www.canonware.com/download/jemalloc/jemalloc-3.6.0.tar.bz2 をダウンロードしてください
tar -xjf jemalloc-3.6.0.tar.bz2

2) コンパイルしてインストールする
cd jemalloc-3.6.0; ./configure; make & make install

3) MySQLを設定する

[mysqld_safe]
malloc-lib=$PATH/libjemalloc.so

4) 参考文書: http://blog.chinaunix.net/uid-29957450-id-4547818.html

my.cnf 設定ファイルリファレンス

# 次のオプションは MySQL クライアント アプリケーションによって読み取られます。 
# このセクションを読み取ることができるのは、MySQL に付属するクライアント アプリケーションのみであることに注意してください。 
# 独自の MySQL アプリケーションでこれらの値を取得する場合。 
# これらのオプションは、MySQL クライアント ライブラリを初期化するときに指定する必要があります。
[クライアント]
ポート = 3306
ソケット = /usr/local/mysql/mysql.sock
# MySQL サーバー [mysqld]
#デフォルトのストレージエンジン INNODB
デフォルトのストレージエンジン=INNODB
#GROUP_CONCAT 長さ group_concat_max_len = 99999
#ポート番号 port = 3306
#ソケットの場所 socket = /usr/local/mysql/mysql.sock 
#pid 書き込みファイルの場所 pid-file = /usr/local/mysql/mysqld.pid
#データベースファイルの場所 datadir = /home/data/mysql/data
ユーザー = mysql
#SQL モードについては、関連情報を参照してください sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
#外部ロックが有効な場合、各プロセスはデータ テーブルにアクセスする必要があります。
#前のプロセスが操作を完了してロックを解除するまで待つ必要があります。サーバーはデータテーブルにアクセスするときにロック解除を待つ必要があることが多いため、
#したがって、外部ロックは単一サーバー環境での MySQL のパフォーマンスを低下させます。
#したがって、多くの Linux ディストリビューションのソースでは、外部ロックを回避するために、MySQL 構成ファイルで skip-external-locking がデフォルトで使用されています。
外部ロックをスキップ
#DNS逆引き解決をスキップ skip-name-resolve
#TIMESTAMP 型のデフォルト値をオフにするexplicit_defaults_for_timestamp

#クライアントの文字セットの影響を受けないため、サーバーの文字セットがskip-character-set-client-handshakeであることを確認してください
#初期接続文字セット UTF8
init-connect='名前をutf8に設定'
#デフォルトのデータベース文字セット character-set-server=utf8

#クエリキャッシュ0、1、2はそれぞれオフ、オン、デマンドを表します
クエリキャッシュタイプ = 1
#単位: 秒。ハンドシェイク時間が connect_timeout を超えると、接続要求は拒否されます。connect_timeout = 20
# マスター データベースからバイナリ ログ イベントが受信されない場合、スレーブがネットワークがタイムアウトしたと見なし、スレーブ IO スレッドがマスター データベースに再接続するまでの秒数を設定します。
#このパラメータのデフォルト値は 3600 秒です。ただし、時間が長すぎると、データベースの遅延が発生したり、プライマリ データベースとスタンバイ データベース間の直接リンクの異常が時間内に検出されなくなったりします。
#slave_net_timeout を非常に短く設定すると、マスターにデータ更新がない場合に頻繁に再接続が発生します。通常、オンライン設定は5秒です 
スレーブ_ネット_タイムアウト = 30

#このパラメータは、サーバーからの更新をバイナリ ログに書き込むかどうかを構成するために使用されます。このオプションはデフォルトでは有効になっていません。
#ただし、このスレーブ サーバー B がサーバー A のスレーブ サーバーであり、サーバー C のマスター サーバーとしても機能する場合は、このオプションを開発する必要があります。
#スレーブサーバーCが同期操作のバイナリログを取得できるようにするため log-slave-updates=1
#スレーブサーバーの場合、IO スレッドは、自身と同じサーバー ID を持つイベントをログに書き込みますが、これは log-slave-updates オプションの replicate-same-server-id=0 と競合します。
# ちなみに、一意の server_id を生成します。考えてみました。誰もが 10.112.87.91 などの一意の IP アドレスを持っているので、ドットを削除して、末尾に 01 または 02 または 03 の数字を追加するだけです (2 桁の数字が追加されるのは、物理マシンが 1 台しかない場合で、マスター スレーブ レプリケーションではそれを識別するために server-id が必要です)。# server_id として 10112879101 を使用します。
サーバーID=10112879101
# バイナリログを有効にします。 
# レプリケーション構成では、このオプションは MASTER サーバーに対してオンにする必要があります。# 最後のバックアップからポイントインタイムリカバリを実行する必要がある場合は、バイナリログ log-bin =/home/data/mysql/binlog/mysql-bin.log も必要です。
#リレーログ リレーログ=mysqlリレーbin
#master-info-repository と relay-log-info-repository がオンになっていて、クラッシュセーフなバイナリログ/スレーブサーバー機能が有効になっています (フラットファイルではなくトランザクションテーブルに情報を保存します)
マスター情報リポジトリ=テーブル
リレーログ情報リポジトリ=テーブル

# binlog バイナリ ログ内のデータベースに書き込まない binlog-ignore-db=mysql # 同期データベースなし
binlog-ignore-db=test # 同期データベースなし
binlog-ignore-db=information_schema # 同期データベースなし
binlog-ignore-db=performance_schema # 同期データベースなし

#binlog バイナリログデータベースに書き込みます binlog-do-db=business_db
binlog-do-db=ユーザーdb
binlog-do-db=plocc_system

#15 ローリングクリーンアップバイナリログ
ログ有効期限日数=15
max_binlog_size = 1073741824 # ビンログのサイズ (1G)

# 1000回のbinlog書き込みごとにbinlogをハードディスクと同期させる sync_binlog = 1000

#どのデータベースのデータがコピーされるかを指定します。replicate-do-db=business_db
複製するDB = ユーザーDB
複製するDB=plocc_system

#イベントスケジューラを開くイベントスケジューラ
イベントスケジューラ=1
#MySQL が一時的に保存できる接続の数。これは、メインの MySQL スレッドが短時間に非常に大量の接続要求を受け取ったときに発生します。
#MySQL 接続数が max_connections に達すると、新しいリクエストはスタックに保存され、接続がリソースを解放するまで待機します。
#スタックの数はback_logです。待機中の接続数がback_logを超えると、接続リソースは付与されません。back_log = 500

#データベース全体の最大接続数(ユーザー) max_connections = 6000
#ユーザーの最大接続数 max_user_connection=3000 
# この制限に達した場合にクライアント接続ごとに許可されるエラーの最大数。 
# このクライアントは、「FLUSH HOSTS」が実行されるか、サーバーが再起動されるまで、MySQL サーバーからブロックされます。# 接続中に無効なパスワードやその他のエラーが発生すると、この値が増加します。 
# グローバルカウンタを取得するには、「Aborted_connects」ステータスを確認します。max_connect_errors = 1844674407370954751
#テーブル記述子のキャッシュサイズ。ファイルのオープン/クローズ回数を減らすことができます。table_open_cache = 2048

# サービスが処理できるリクエスト パケットの最大サイズと、サービスが処理できるリクエストの最大サイズ (大きな BLOB フィールドを扱う場合に重要) 
# 各接続には独立したサイズがあります。サイズは動的に増加します。max_allowed_pa​​cket = 64M
# トランザクション内の SQL ステータスを記録するために binlog が保持するキャッシュのサイズ。# 大規模な複数ステートメントのトランザクションを頻繁に使用する場合は、この値を増やすとパフォーマンスが向上します。 
# トランザクションのすべての状態は binlog バッファにバッファリングされ、コミットされると binlog に書き込まれます。# トランザクションがこの値より大きい場合は、代わりにディスク上の一時ファイルが使用されます。 
# このバッファは、各接続のトランザクションが初めて状態を更新したときに作成されます binlog_cache_size = 1M
# スタンドアロン メモリ テーブルに許可される最大サイズ。 
# このオプションは、すべてのメモリ リソースを使い果たす大きすぎるメモリ テーブルが誤って作成されるのを防ぐためのものです。
最大ヒープテーブルサイズ = 1342177280
# ソートバッファはORDER BYおよびGROUP BYキューによるソートを処理するために使用されます。# ソートされたデータがソートバッファに収まらない場合は、 
# 代替のディスクベースのマージソートが使用されます。 # 「Sort_merge_passes」ステータス変数を参照してください。 
# sort_buffer_size = ソートが発生したときに各スレッドによって割り当てられる 8M
# このバッファは、完全 JOIN (インデックスなしの結合) を最適化するために使用されます。 
# 類似結合はほとんどの場合パフォーマンスが非常に悪いです。 
# ただし、この値を高く設定すると、パフォーマンスへの影響を軽減できます。 
# 「Select_full_join」ステータス変数で完全結合の数を確認します。# 完全結合が発生すると、各スレッドに join_buffer_size = 8M を割り当てます。
# 再利用のためにキャッシュに保持するスレッドの数 # クライアントが切断したときに、キャッシュ内のスレッド数がthread_cache_sizeより少ない場合、 
# クライアントスレッドはキャッシュに格納されます。 
# これにより、多数の新しい接続が必要な場合にスレッド作成のオーバーヘッドを大幅に削減できます # (一般的に、優れたスレッド モデルを使用している場合、パフォーマンスは目立った向上は見られません。)
スレッドキャッシュサイズ = 128
# これにより、アプリケーションは、同時に実行するスレッドの数についてのヒントをスレッド システムに提供できるようになります。 
# この値は、thread_concurrency() 関数をサポートするシステム (Sun Solaris など) でのみ意味を持ちます。 
# thread_concurrency 値として [CPU 番号]*(2..4) を使用できます。thread_concurrency = 8
# クエリバッファリングは、SELECT 結果をキャッシュし、次回同じクエリを実行せずに結果を直接返すためによく使用されます。 
# 同一のクエリが多数あり、テーブルをほとんど変更しない場合は、クエリ キャッシュを有効にするとサーバーの速度が大幅に向上します。 
# 「Qcache_lowmem_prunes」ステータス変数をチェックして、現在の値が負荷に対して十分に高いかどうかを確認します。 
# 注意: テーブルが頻繁に変更される場合や、クエリテキストが毎回異なる場合は、 
# クエリキャッシュにより、パフォーマンスが向上するのではなく低下する可能性があります。
クエリキャッシュサイズ = 64M
# この設定より小さい結果のみがキャッシュされます # この設定はクエリキャッシュを保護するために使用され、非常に大きな結果セットが他のすべてのクエリ結果を上書きするのを防ぎます query_cache_limit = 2M
# 全文検索でインデックスされる単語の最小の長さ。 
# より短い単語を検索する必要がある場合は、この値を減らすことをお勧めします。 
# この値を変更した後は、 
# FULLTEXTインデックスを再構築する必要があります ft_min_word_len = 4
# スレッドが使用するヒープ サイズ。このメモリ量は接続ごとに予約されます。 
# MySQL 自体は通常 64K 以上のメモリを必要としません。# 大量のヒープを必要とする独自の UDF を使用する場合、# またはオペレーティング システムが特定の操作にさらにヒープを必要とする場合は、 
# これをもっと高く設定することもできます。 
スレッドスタック = 192K
# デフォルトのトランザクション分離レベルを設定します。使用可能なレベルは次のとおりです。 
# READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE
transaction_isolation = READ-COMMITTED
# 内部 (メモリ内) 一時テーブルの最大サイズ # テーブルがこの値より大きくなると、自動的にディスクベースのテーブルに変換されます。 
# この制限は合計ではなく個々のテーブルに適用されます。
tmp_テーブルサイズ = 1342177280

#binlog ログタイプ -- 混合 binlog_format=mixed
#スロークエリログを開く slow_query_log
#ファイル形式 log_output = FILE
# この時間 (秒単位) より長くかかるすべてのクエリは、遅いクエリとみなされます。 
# ここで「0」を使用しないでください。そうしないと、非常に高速なクエリも含め、すべてのクエリが記録されます (MySQL の時間精度は現在秒単位のみであるため)。 
長いクエリ時間 = 0.5
#スロークエリログの場所 slow_query_log_file=/usr/local/mysql/mysqld_slow.log
#インデックスバッファのサイズを指定します。これはインデックス処理の速度、特にインデックスの読み取り速度を決定します。#******************** MyISAM 関連のオプション********************************
# キーワード バッファのサイズ。通常は MyISAM テーブルのインデックス ブロックをバッファリングするために使用されます。 
# 使用可能なメモリの30%より大きく設定しないでください。 
# メモリの一部は OS によって行データをキャッシュするためにも使用されるため # MyISAM テーブルを使用しない場合でも、内部の一時ディスク テーブルによっても使用されるため、8-64M のメモリを設定する必要があります。
キーバッファサイズ = 32M
# MyISAM テーブルの完全なテーブルスキャンに使用されるバッファ サイズ。 
# 完全なテーブルスキャンが必要な場合は、対応するスレッドに割り当てられます。
読み取りバッファサイズ = 2M
# ソート後にすでにソートされたシーケンスから行を読み取る場合、ディスクシークを回避するために行データはこのバッファから読み取られます。 
# この値を増やすと、ORDER BY のパフォーマンスが大幅に向上します。 
# 必要に応じて各スレッドで read_rnd_buffer_size = 8M を割り当てます
# MyISAMは特別なツリー状のキャッシュを使用してバースト挿入を行います(これらの挿入は、INSERT ... SELECT、INSERT ... VALUES (...)、(...)、...、およびLOAD DATAです)。 
# INFILE の高速化。この変数はプロセスごとのキャッシュ ツリーのバイト数を制限します。 
# これを 0 に設定すると、この最適化は無効になります。 
# 最適化のため、この値を「key_buffer_size」より大きく設定しないでください。 
# このバッファはバースト挿入が検出されたときに割り当てられます。
バルク挿入バッファサイズ = 16M
# このバッファは、MySQL が空のテーブルに対して REPAIR、OPTIMIZE、ALTER、および LOAD DATA INFILE を実行する際にインデックスを再構築する必要があるときに割り当てられます。 
# これはスレッドごとに割り当てられます。そのため、大きな値を設定する場合は注意してください。
myisam_sort_buffer_size = 128M
# インデックスを再構築するときに MySQL が許可する一時ファイルの最大サイズ (REPAIR、ALTER TABLE、または LOAD DATA INFILE の場合)。 
# ファイルサイズがこの値より大きい場合、インデックスはキー値バッファを介して作成されます(低速) 
myisam_max_sort_file_size = 1G
# テーブルに複数のインデックスがある場合、MyISAM は複数のスレッドを使用して並列にソートすることでそれらを修復できます。 
# これは、複数の CPU と大量のメモリを持つユーザーに適しています。
myisam_repair_threads = 1
# 適切に閉じられなかった MyISAM テーブルを自動的にチェックして修復します。 
マイサム回復

# *************** INNODB 関連オプション************************ 
# MySQLサーバーにInnoDBサポートが含まれているが、それを使用する予定がない場合は、 
# このオプションを使用すると、メモリとディスク容量が節約され、一部の部分が高速化されます #skip-innodb

# #####[重要アイテム]
# InnoDB は、MyISAM とは異なり、バッファー プールを使用してインデックスと生データを格納します。 
# 設定値を大きくするほど、テーブル内のデータにアクセスするために必要なディスク I/O が少なくなります。 
# スタンドアロン データベース サーバーでは、この変数をサーバーの物理メモリ サイズの 80% に設定できます。 
# あまり大きく設定しないでください。大きく設定すると、物理メモリの競合により、オペレーティング システムでページング ジッターが発生する可能性があります。 
# 32ビットシステムでは、プロセスごとに2〜3.5Gのユーザーレベルメモリに制限される可能性があることに注意してください。 
# あまり高く設定しないでください。
innodb_buffer_pool_size = 700m #1G
# InnoDB は、データを 1 つ以上のデータ ファイルにテーブルスペースとして保存します。 
# データを保持する論理ドライブが 1 つしかない場合は、自動増分ファイル 1 つで十分です。 
# その他の場合は、デバイスごとに 1 つのファイルを選択するのが通常は適切です。 
# InnoDB を raw パーティションを使用するように構成することもできます - 詳細についてはマニュアルを参照してください innodb_data_file_path = IBdata1:1024M;IBdata2:1024M:autoextend
# InnoDB テーブルスペース ファイルを別のパーティションに保存する場合は、このオプションを設定します。 
# デフォルトでは MySQL データディレクトリに保存されます。 
#innodb_data_home_dir = 
# IO操作を同期するために使用されるIOスレッドの数。この値は 
# この値は Unix では 4 にハードコードされていますが、Windows では値が大きいほどディスク I/O のパフォーマンスが向上する可能性があります。 
innodb_file_io_threads = 4
# InnoDb コアで許可されるスレッドの数。 
# 最適な値は、アプリケーション、ハードウェア、およびオペレーティング システムのスケジュールによって異なります。 
# 値が高すぎると、スレッドミューテックスのスラッシングが発生する可能性があります。
innodb_thread_concurrency = 16
# #####[重要アイテム]
# 1 に設定すると、InnoDB はコミットごとにトランザクション ログをディスクにフラッシュ (fsync) します。 
# これにより、完全な ACID 動作が提供されます。 
# トランザクションの安全性を犠牲にしても構わず、小さなトランザクションを実行している場合は、この値を 0 または 2 に設定して、トランザクション ログによって発生するディスク I/O を削減できます。 
# 0 は、ログが約 1 秒ごとにログ ファイルに書き込まれ、ログ ファイルがディスクにフラッシュされることを意味します。 
# 2 は、各コミット後にログがログ ファイルに書き込まれるが、ログ ファイルは約 1 秒ごとにのみディスクにフラッシュされることを意味します。 
# --------------------
# (注: ゲーム サーバーの場合は、この値を 2 に設定することをお勧めします。データ セキュリティ要件が非常に高いアプリケーションの場合は、1 に設定することをお勧めします。
# 0 に設定すると最高のパフォーマンスが得られますが、障害が発生した場合はデータが失われる可能性があります。
# デフォルト値 1 は、トランザクションのコミットまたはトランザクション外の命令ごとにログをハードディスクにフラッシュする必要があることを意味し、非常に時間がかかります。
# 特にバッテリーバックアップキャッシュを使用する場合。多くのアプリケーションでは、特に MyISAM テーブルから転送する場合は、これを 2 に設定すると問題ありません。
# ハードディスクに書き込むのではなく、システムキャッシュに書き込むことを意味します。ログは毎秒ディスクにフラッシュされるため、通常は 1 ~ 2 秒以上の更新が失われることはありません。
# 0 に設定すると高速になりますが、安全性は低下します。MySQL がクラッシュした場合でも、トランザクション データが失われる可能性があります。値が 2 の場合、オペレーティング システム全体がクラッシュした場合にのみデータが失われる可能性があります。
innodb_flush_log_at_trx_commit = 2

# ログデータをバッファリングするために使用されるバッファのサイズ。 
# この値がほぼいっぱいになると、InnoDB はデータをディスクにフラッシュする必要があります。 
# ほぼ毎秒更新されるため、この値を大きく設定する必要はありません(長いトランザクションの場合でも) 
innodb_log_buffer_size = 16M

# ログ グループ内の各ログ ファイルのサイズ。 
# ログファイルのサイズをバッファプールサイズの25%~100%に設定する必要があります 
# ログ ファイルの上書き時に不要なバッファー プールのフラッシュを回避するため。 
# ただし、ログファイルのサイズが大きいと、リカバリプロセスに必要な時間が長くなることに注意してください innodb_log_file_size = 1024M

# ログ グループ内のファイルの総数。 
# 一般的には2~3が良いでしょう。 
innodb_log_files_in_group = 3

# InnoDB ログ ファイルの場所。デフォルトは MySQL datadir です。 
# パフォーマンスを向上させるために、別のハードディスクまたは RAID1 ボリュームに割り当てることができます #innodb_log_group_home_dir

# InnoDB バッファ プール内のダーティ ページの最大許容比率。 
# 制限に達した場合、InnoDB はクリーンなデータ ページへの干渉を防ぐためにそれらのフラッシュを開始します。 
# これはソフト制限であり、強制されることは保証されません。 
innodb_max_dirty_pages_pct = 90

# InnoDB がログをフラッシュするために使用する方法。 
# テーブルスペースは常にデュアル書き込みフラッシュ方式を使用します # デフォルト値は「fdatasync」、もう 1 つは「O_DSYNC」です。 
innodb_flush_method=O_DSYNC

# InnoDB トランザクションがロールバックされる前にロックが許可されるまで待機する時間。 
# InnoDB は、独自のロック テーブルでトランザクションのデッドロックを自動的に検出し、トランザクションをロールバックします。 
# LOCK TABLES ディレクティブを使用したり、同じトランザクションで InnoDB 以外のトランザクションセーフ ストレージ エンジンを使用したりすると、InnoDB が気付かないうちにデッドロックが発生する可能性があります。 
# この場合、このタイムアウト値は問題を解決するのに非常に役立ちます。 
innodb_lock_wait_timeout = 30

[mysqlダンプ]
# ディスクに書き込む前に、結果全体をメモリにキャッシュしないでください。これは、非常に大きなテーブルをエクスポートするときに必要です。

最大許容パケット = 64M

[mysql]
自動再ハッシュなし

[マイサムチク]
キーバッファサイズ = 512M
ソートバッファサイズ = 512M
読み取りバッファ = 8M
書き込みバッファ = 8M

[mysqlホットコピー]
対話タイムアウト

[mysqld_safe]
# プロセスごとに開いているファイルの数を増やします。 
# 警告: システム全体の制限が十分に高く設定されていることを確認してください。 
# 多数のテーブルを開くには、この値をより大きな値に設定する必要があります open-files-limit = 8192
ログエラー=/usr/local/mysql/mysqld.log
pid ファイル = /usr/local/mysql/mysqld.pid

MYSQL パフォーマンス最適化は、これらのコンテンツだけではありません。他にも多くのコンテンツがあります。当社の Web サイトで、その他の MYSQL パフォーマンス最適化ソリューションを検索できます。

以下もご興味があるかもしれません:
  • MySQL パフォーマンスの包括的な最適化方法リファレンス、CPU、ファイルシステムの選択から mysql.cnf パラメータの最適化まで
  • MySQL パフォーマンス最適化のための 20 以上のベストヒント
  • MySQL パフォーマンス最適化ツールの使用入門 - チューナー入門
  • MySQLデータベースのパフォーマンス最適化の詳細な説明
  • MySQL パフォーマンスパラメータ Skip-External-Locking パラメータの詳細な説明
  • MySQL パフォーマンス パラメータの詳細な説明: Max_connect_errors の使用
  • MySQL パフォーマンスのボトルネックのトラブルシューティングと場所の例
  • MySQL パフォーマンス最適化ソリューションの共有
  • MySQL パフォーマンス最適化の事例 - インデックス共有のカバー
  • MySQL パフォーマンス最適化のケーススタディ - インデックスと SQL_NO_CACHE をカバー
  • MySQL パフォーマンス最適化インデックス最適化
  • MySQL パフォーマンス監視ソフトウェア Nagios のインストールと設定のチュートリアル
  • 19 MySQL パフォーマンス最適化ポイント分析
  • MySQL パフォーマンス最適化の詳細解説(パート 2)
  • MySQL パフォーマンス最適化の詳細解説(パート 1)
  • MySQL のパフォーマンスを最適化する 10 の方法
  • InnoDB 分離モードが MySQL のパフォーマンスに与える影響についての簡単な説明
  • FriendFeed を使用して MySQL のパフォーマンスを向上させる方法

<<:  docker ベースの redis-sentinel クラスターの構築例

>>:  React の国際化 react-intl の使用

推薦する

Reactでプロキシを有効にする2つの実用的な方法

プロキシを有効にする2つの方法React には、直接使用できるカプセル化された Ajax リクエスト...

H5ウェイクアップアプリの実装方法と注意点のまとめ

目次序文APPメソッドにジャンプURLスキームメタタグユニバーサルリンクさまざまな使い方URLスキー...

MySQL にテーブルが存在するかどうかを確認し、それを一括で削除する方法

1. インターネットで長時間検索しましたが、判定表が存在するかどうかがわからなかったので、漠然と削除...

Nginx と Lua を使用した JWT 検証の概要

目次序文Lua スクリプトnignx.conf の設定Dockerfileの設定序文データベースやそ...

Docker 構成コンテナの場所とヒントのまとめ

Docker の使用に関するヒント1. 停止したDockerコンテナをすべてクリーンアップする停止し...

js でオブジェクトを作成するさまざまな方法とその長所と短所のまとめ

目次初期作成方法ファクトリーパターンコンストラクターパターンコンストラクタパターンの最適化プロトタイ...

Debian Dockerコンテナにcrontabスケジュールタスクを追加する

現在、DockerイメージのほとんどはDebianベースです # cat /etc/issue De...

Vueは書籍ショッピングカートの機能を実現

この記事の例では、書籍ショッピングカート機能を実現するためのVueの具体的なコードを参考までに共有し...

Linux 環境での Oracle 導入チュートリアル

1. 環境と関連ソフトウェア仮想マシン: VMwore Workstation Linuxシステム:...

Bash スクリプトを使用して Linux のメモリ使用量を監視する方法

序文Linux システムのパフォーマンスを監視するために使用できるオープンソースの監視ツールが市場に...

Nodejs のグローバル変数とグローバルオブジェクトの知識ポイントと使用方法の詳細

1. グローバルオブジェクトすべてのモジュールは呼び出すことができます1) global: ブラウザ...

MySqlは指定されたユーザーのデータベースビュークエリ権限を設定します

1. 新しいユーザーを作成します。 1. SQL ステートメントを実行して新しいものを作成します (...

ubuntu18.04 での qt5.12.8 のインストールと環境設定に関する詳細なチュートリアル

環境システム: Ubuntu 18.04ソフトウェア: qt5.12.8 1. インストールパッケー...

5分でReactルーティングについてお教えします

目次ルーティングとは純粋コンポーネントの基本的な使用純粋なコンポーネントの使用に関する注意事項ルーテ...

HTML タグのメタ概要、HTML5 のヘッド メタ属性の概要

序文metaはhtml言語のhead領域にある補助タグです。おそらく、これらのコードは不要だと思うで...