CyberPanelでMySQLの書き込みパフォーマンスを改善し、MySQLインストール後のパフォーマンスを最適化する方法

CyberPanel の MySQL 書き込みパフォーマンス最適化ガイド

CyberPanel をご利用の場合、MySQL への書き込み速度が遅くなることがあります。通常、データベースへの書き込みに異常はありませんが、ウェブサイトのトラフィックが増加すると、データベースの速度が非常に遅くなります。

この時点で、CPUとメモリはまだアイドル状態であり、占有されているのは30%未満で、帯域幅にも余裕があることがわかります。なぜデータベースへの書き込みが遅くなるのでしょうか？

デフォルトでインストールされたデータベースは最適化されていません。MySQLデータベースを最適化する方法を見てみましょう。

MySQLの書き込みパフォーマンスを最適化するには、ハードウェア、構成、クエリ設計、監視の調整が必要です。実際のワークロード（大量の同時書き込みなど）によっては、最適化によってパフォーマンスが2～10倍向上する可能性があります。

CyberPanel で MySQL を最適化する方法は次のとおりです。

まず、監視ツールをインストールします: sudo apt install mysql-tuner-perl、そして perl mysql-tuner.pl を実行して、innodb_buffer_pool_size を増やすなどの予備的な提案を取得します。

データベース構成ファイルを開く

vi /etc/mysql/mariadb.conf.d/50-server.cnf

[mysqld] bind-address = 127.0.0.1 # リモートからの不正アクセスを避けるためローカルにバインド default_storage_engine = InnoDB # デフォルトの InnoDB (トランザクションをサポート) character-set-server = utf8mb4 # 絵文字をサポート collation-server = utf8mb4_unicode_ci

設定ファイルにない場合は、[mysqld] に追加します。

InnoDBバッファプールを最適化します。書き込みのボトルネックは、InnoDBのログ、バッファ、ロックで発生することがよくあります。徐々に調整し、変化を監視してください。

innodb_buffer_pool_size = 70% システム RAM を設定します。

innodb_buffer_pool_size = 44G innodb_buffer_pool_instances = 8 # 複数のインスタンスはロックの競合を減らす

高性能ウェブアプリケーションにおいて、データベースエンジンとしてのMariaDB（MySQL互換）は、デフォルト設定ではサーバーのポテンシャルを十分に活用できないことがよくあります。例えば、64GBのRAMを搭載している場合、デフォルトのInnoDBバッファプールはわずか128MBで、推奨される70%のRAM（約45GB）を大きく下回っています。これは、頻繁なディスクI/O、クエリのレイテンシ、書き込みボトルネックにつながる可能性があります。MariaDBの公式ベンチマークと2025年のPerconaレポートによると、最適化されていない設定でのTPS（1秒あたりのトランザクション数）は、ピーク時でもわずか30%です。しかし、最適化を行うことで、特にeコマースやCMSなどの高同時実行シナリオでは、この数値は4～8倍に向上する可能性があります。

CyberPanelでのMySQLの最適化は一度きりの作業ではなく、反復的なプロセスです。基本設定から始め、ダッシュボードツールやモニタリングツールと組み合わせることで、パフォーマンスを大幅に向上させ、一般的なボトルネックを回避できます。最適化後は、負荷テスト（JMeterシミュレーションなど）を行い、mysql-tunerを定期的に実行してください。2025年までにAI駆動型データベースツールの台頭により、CyberPanelとの連携はさらにスマートになりますが、手動によるチューニングは依然として基本的な作業です。最適化が完了すれば、ウェブサイトの効率が向上し、ビジネスの飛躍に貢献します。

MySQL 一時テーブルディスク作成の最適化: しきい値を 46% から 25% に削減するための実践ガイド

MySQL のパフォーマンスチューニングでは、一時テーブルが作成される場所がクエリの効率とリソース消費に直接影響します。現在の状況では、Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables) * 100 = 46% となり、推奨しきい値の 25% を大幅に上回っています。これは、これらの一時テーブルのほぼ半分がメモリではなくディスクに保存されていることを意味しており、I/O オーバーヘッドの急増、クエリのレイテンシの 2 倍の増加、さらには高同時実行時のボトルネックの原因にもなっています。式 (値 > 25) に基づくと、mysql-tuner などのツールで警告がトリガーされます。一時テーブルは、GROUP BY、ORDER BY、または DISTINCT 操作でよく使用されます。メモリが不足すると、MySQL は自動的にディスク (MyISAM エンジン) に切り替えます。これは、64 GB の RAM を搭載したサーバーでは発生しないはずですが、最適ではない構成またはクエリ設計の問題を示している可能性があります。

まず、パラメータを同時に調整します。つまり、 max_heap_table_size = tmp_table_size = 1024MB（1.6%のRAMを占有）に設定します。そのためには、 my.cnf の [mysqld] セクションに次の行を追加し、MariaDBを再起動してテストします。 SHOW GLOBAL STATUS LIKE 'Created_tmp%'; を監視し、25%未満まで削減することを目指します。それでも問題が解決しない場合は、クエリを書き直します。つまり、遅いSQLをEXPLAINで分析するか、BLOBフィールドを外部ストレージに分割するか、クエリキャッシュを有効にします。これをPercona Toolkitのpt-query-digestと組み合わせてログを分析し、最適化を反復します。最終的には、一時テーブルのメモリヒット率が80%を超えるだけでなく、全体的なパフォーマンスが2～4倍向上し、データベースがかろうじて生き残る状態から応答性に優れた状態になります。

tmp_table_size = 1024M、max_heap_table_size = 1024M

MySQLのlong_query_time設定の最適化：10秒を1～5秒に短縮するためのガイド

MySQLパフォーマンスモニタリングでは、long_query_timeパラメータがスロークエリログのしきい値を定義します。この値を超えるクエリは「スロークエリ」として記録され、後続の分析と最適化に使用されます。現在の設定（10秒以上）では、非常に遅いクエリ（複雑な結合や大規模なテーブルスキャンなど）のみがキャプチャされるため、多くの潜在的なボトルネックが見逃され、パフォーマンスの問題が顕在化しない可能性があります。MySQLのドキュメントとPerconaのベストプラクティスによると、デフォルトの10秒のしきい値は低負荷のテスト環境には適していますが、本番サーバー（1日のクエリ数が10万件を超える）ではスロークエリログがまばらになりすぎて、インデックスの欠落やロック競合などの問題をタイムリーに特定できなくなります。その結果、データベースの応答時間がわずかに増加し、ユーザーエクスペリエンスが低下し、TPS（1秒あたりのトランザクション数）が20～50%減少します。

現在の分析：long_query_time のしきい値 10 は、式（値 >= 10）に基づいて直接検証されており、mysql-tuner などのツールで警告をトリガーします。10 秒のしきい値は、1～5 秒の「中程度に遅いクエリ」を無視します。これらのクエリは、多くの場合、高いリターンが得られる最適化の機会（例：EXPLAIN を使用した分析）を提供します。トラフィック量の多いシナリオでは、しきい値を 1～5 秒に調整することをお勧めします。1 秒はリアルタイムアプリケーション（e コマースなど）に適しており、2～3 秒は汎用的な用途に適しており、5 秒はレポートワークロードに適しています。しきい値を短くするとログの量は増えますが、ディスク負荷を回避するためにログサイズ（/var/log/mysql/mariadb-slow.log）を監視する必要があります。

long_query_time = 5 # 負荷テストに基づいて 1 ～ 5 秒を推奨 slow_query_log = 1 # スロー クエリ ログを有効にする (有効になっていない場合) slow_query_log_file = /var/log/mysql/mariadb-slow.log log_slow_verbosity = query_plan,explain # 実行プランを記録する log_queries_not_using_indexes = 1 # インデックスを使用しないクエリを記録する log_slow_admin_statements = 1 # 管理ステートメントを記録する

チューニング後、スロークエリログにはより詳細な情報が記録されるようになり、問題を迅速に特定し、クエリ全体の速度を30%以上向上させることができます。ただし、ログファイルのサイズは増加します（1日あたり10～100MB）。logrotate /var/log/mysql/mariadb-slow.log を使用して、定期的にローテーションしてください。高負荷環境では、EXPLAINとインデックス最適化を組み合わせて、過剰なログ出力を回避してください。定期的にmysql-tunerを実行し、しきい値が実際のニーズに合致していることを確認してください（例えば、2秒から3秒に調整するなど）。

これらの調整を行うことで、MySQLデータベースの俊敏性が向上し、ウェブサイトの運用効率が向上します。最適化は継続的なプロセスであり、Grafanaなどの監視ツールと組み合わせることで、さらに優れた結果が得られます。

以下は実稼働環境で使用できる完全なMySQL構成です。

# # これらのグループはMariaDBサーバーによって読み取られます。 # サーバーのみ (クライアントは含まない) に表示されるオプションに使用します # これは、スタンドアロン デーモンおよび組み込みサーバーによって読み取られます [server] # これは、mysqld スタンドアロン デーモン専用です [mysqld] # # * 基本設定 # #user = mysql pid-file = /run/mysqld/mysqld.pid basedir = /usr #datadir = /var/lib/mysql #tmpdir = /tmp # 逆 DNS が壊れていると接続速度がかなり低下するため、"host by domain name" アクセス許可がない場合は、名前解決をスキップしても安全です #skip-name-resolve # skip-networking の代わりに、デフォルトでは、互換性が高く、安全性も低い localhost のみで listen するようになりました。 bind-address = 127.0.0.1 # # * 微調整 # key_buffer_size = 512M max_allowed_packet = 2G thread_stack = 192K thread_cache_size = 1024 tmp_table_size = 1024M max_heap_table_size = 1024M open_files_limit = 0 #key_buffer_size = 128M #max_allowed_packet = 1G #thread_stack = 192K #thread_cache_size = 8 # これは起動スクリプトを置き換え、必要に応じてMyISAMテーブルを最初にアクセスしたときにチェックします #myisam_recover_options = BACKUP #max_connections = 100 #table_cache = 64 myisam_recover_options = BACKUP max_connections = 9999 table_open_cache = 40000 # # * ログ記録とレプリケーション # # 注: 構成されたログ ファイルまたはそのディレクトリを作成し、mysql ユーザーが書き込み可能である必要があります。例: # $ sudo mkdir -m 2750 /var/log/mysql # $ sudo chown mysql /var/log/mysql # 両方の場所は cronjob によってローテーションされます。 # このログ タイプはパフォーマンス キラーであることに注意してください。 # 必要な場合にのみ、短いテスト期間の実行時にこれを変更することをお勧めします。 #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # systemd で実行している場合、エラー ログは stdout/stderr 経由で journald に記録されます # また、レガシー init を実行している場合は、エラー ログは # /etc/mysql/conf.d/mariadb.conf.d/50-mysqld_safe.cnf のため syslog に記録されます # エラーを別のファイルに記録する場合は、これを有効にします #log_error = /var/log/mysql/error.log # 特に実行時間の長いクエリを確認するには、スロー クエリ ログを有効にします #log_slow_query_file = /var/log/mysql/mariadb-slow.log #log_slow_query_time = 10 #log_slow_verbosity = query_plan,explain #log-queries-not-using-indexes #log_slow_min_examined_row_limit = 1000 long_query_time =5 # 負荷テストに基づき、1～5 秒を推奨 slow_query_log = 1 # スロー クエリ ログを有効にする (有効でない場合) slow_query_log_file = /var/log/mysql/mariadb-slow.log log_slow_verbosity = query_plan,explain # 実行プランを記録する log_queries_not_using_indexes = 1 # インデックスを使用していないクエリを記録する log_slow_admin_statements = 1 # 管理ステートメントを記録する # 以下は、簡単に再生できるバックアップ ログとして、またはレプリケーションに使用できます。 # 注: レプリカを設定する場合は、変更する必要がある可能性のあるその他の # 設定について、README.Debian を参照してください。 #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 #max_binlog_size = 100M # # * SSL/TLS # # ドキュメントについては、# https://mariadb.com/kb/en/securing-connections-for-client-and-server/ をお読みください。#ssl-ca = /etc/mysql/cacert.pem #ssl-cert = /etc/mysql/server-cert.pem #ssl-key = /etc/mysql/server-key.pem #require-secure-transport = on # # * 文字セット # # MySQL/MariaDB のデフォルトは Latin1 ですが、Debian ではデフォルト# utf8 4バイト文字セットに完全準拠します。client.cnf も参照してください。character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci # # * InnoDB # # InnoDBはデフォルトで有効になっており、/var/lib/mysql/ に10MBのデータファイルが作成されます。# InnoDB関連のオプションについては、マニュアルをご覧ください。他にもたくさんあります！ # 最も重要なのは、InnoDB にシステム RAM の 80 % をバッファ使用用に割り当てることです: # https://mariadb.com/kb/en/innodb-system-variables/#innodb_buffer_pool_size #innodb_buffer_pool_size = 8G innodb_buffer_pool_size = 48G innodb_buffer_pool_instances = 16 innodb_log_file_size = 12G innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_io_capacity = 2000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 # これは組み込みサーバー専用です [embedded] # このグループは読み取り専用ですMariaDB サーバーによって使用されますが、MySQL によって使用されることはありません。# MySQL と MariaDB で同じ .cnf ファイルを使用する場合、# MariaDB 専用のオプションをここに配置できます [mariadb] # このグループは MariaDB-10.11 サーバーによってのみ読み取られます。# 異なるバージョンの MariaDB で同じ .cnf ファイルを使用する場合、# 古いサーバーが理解できないオプションにはこのグループを使用します [mariadb-10.11]

スコア