はじめに：なぜmy.iniの最適化が重要なのか
データベース管理者として日々現場に立っていると、パフォーマンス劣化の相談を受ける機会が多くあります。その原因の多くは、アプリケーションのクエリの問題ではなく、MySQLの動作を決める設定ファイル（Windows環境ではmy.ini、Linux環境ではmy.cnf）が、サーバのスペックやワークロードに適していないことにあります。
デフォルト設定のまま運用していると、メモリの無駄遣いが発生したり、逆にI/Oボトルネックが顕著になったりします。本記事では、実務レベルで最低限押さえておくべきmy.iniの最適化手法と、運用管理における注意点を解説します。
メモリ管理の要：バッファプールとキャッシュ
MySQLのパフォーマンスを左右する最大の要素は、メモリの効率的な利用です。特にInnoDBストレージエンジンを使用している場合、innodb_buffer_pool_sizeの設定が最重要項目となります。
この値は、データとインデックスをメモリ上に保持する領域を定義します。物理メモリの70%〜80%を目安に設定するのが定石ですが、サーバ上で他にWebサーバやAPサーバが同居している場合は注意が必要です。
設定例：
[mysqld]
物理メモリが16GBの場合、10GB程度を割り当てる例
innodb_buffer_pool_size = 10G
また、innodb_buffer_pool_instancesを適切に設定することで、マルチスレッド環境での競合を減らすことができます。
設定例：
innodb_buffer_pool_instances = 8
ログとリカバリ設定の最適化
実務では、パフォーマンスだけでなく「障害時の復旧」も考慮しなければなりません。特にバイナリログ（binlog）とInnoDBのトランザクションログ（redo log）の設定は、データ整合性と書き込み性能のトレードオフになります。
innodb_flush_log_at_trx_commitは、トランザクションのコミット時にログをディスクに書き出すタイミングを制御します。
設定例：
1は最も安全だが書き込み負荷が高い
2はOSクラッシュ時に1秒分のデータが失われる可能性があるが高速
innodb_flush_log_at_trx_commit = 1
開発環境や、多少のデータ消失を許容できる分析用サーバであれば、この値を2にすることで劇的に書き込み性能が向上します。しかし、金融系や決済関連など、一貫性が求められるシステムでは必ず1を設定してください。
接続管理とコネクションプール
max_connectionsの設定は、アプリケーションからの接続数に直結します。多すぎるとメモリを消費し、少なすぎると「Too many connections」エラーが発生します。
設定例：
max_connections = 500
ここで重要なのは、MySQL側の設定だけでなく、アプリケーション側（コネクションプール）の設定と整合性を取ることです。MySQL側で接続数を増やしても、アプリケーション側のコネクションプールが適切に管理されていないと、DB側に無駄なスレッドが生成され、コンテキストスイッチのオーバーヘッドが増大します。
一時テーブルとソート処理
複雑なクエリを実行する際、メモリ上に乗り切らないデータはディスク上の「一時テーブル」として書き出されます。tmp_table_sizeとmax_heap_table_sizeを適切に設定することで、このディスクI/Oを抑制できます。
設定例：
tmp_table_size = 64M
max_heap_table_size = 64M
この値が小さすぎると、頻繁にディスク一時テーブルが作成され、クエリのレスポンスが極端に悪化します。逆に大きくしすぎるとメモリ不足を招くため、スロークエリログを確認しながら調整を行うのが実務上の定石です。
スロークエリログによる継続的改善
設定ファイルは「一度決めたら終わり」ではありません。MySQLのパフォーマンス改善は、設定変更と計測の繰り返しです。そのために不可欠なのがスロークエリログの設定です。
設定例：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1.0
log_queries_not_using_indexes = 1
long_query_timeは、何秒以上かかったクエリを記録するかを指定します。本番環境では、まずは1秒に設定し、明らかに遅いクエリを撲滅してから、徐々に閾値を下げていくアプローチが有効です。log_queries_not_using_indexesを有効にすることで、インデックスが効いていないクエリを可視化でき、インデックス設計の見直しに直結します。
設定ファイル管理のベストプラクティス
最後に、DBAとして推奨したい「設定ファイル管理の運用ルール」を共有します。
1. バージョン管理：my.iniは必ずGitなどでバージョン管理してください。いつ、誰が、どの値を変えたのかを追跡できるようにすることは、障害時の切り戻しにおいて必須です。
2. 設定の検証：設定を変更した際は、必ずmysqld –help –verboseを行い、設定が正しく反映されているかを確認してください。特に単位（M, G, Kなど）の間違いは、起動失敗の主要な原因です。
3. 段階的な適用：一度に複数のパラメータを変更してはいけません。変更は一つずつ行い、その都度パフォーマンスの変動をモニタリングしてください。
4. コメントの徹底：なぜその値を設定したのか、根拠をコメントとして記述してください。例えば「# 2023-10-27 負荷試験の結果、メモリ不足のため10Gから8Gへ縮小」といったメモがあるだけで、後任の運用担当者が助かります。
まとめ
MySQLの設定ファイル（my.ini）は、データベースの心臓部を制御する重要なインターフェースです。スペックに対して過剰な設定をすればリソースを食いつぶし、過小な設定をすれば性能を殺してしまいます。
実務においては、自身の環境における「ベースライン（現在の性能）」を把握し、ボトルネックを特定した上で、最小限の変更を加えていく慎重さが求められます。この記事が、皆さんのMySQL運用の一助となれば幸いです。
最後に、設定変更を行う際は、必ずバックアップを取得し、開発環境で十分なテストを経てから本番環境へ適用するようにしてください。データベースの安定稼働は、こうした地道な設定の積み重ねによって支えられています。
コメント