WordPress には、データベースの接続プールを有効にする設定がありません。WordPress（PHP）はページを表示するリクエストごとに MySQL / MariaDB へ接続し、処理が終わると接続を閉じます。そのため、wp-config.php や php.ini に何かを書き足しても接続プールにはなりません。接続数の問題を解決するには、①PHP-FPM のプロセス数で同時接続数の上限を決め、②MySQL の max_connections をそれに合わせ、③それでも足りない構成では ProxySQL のような外部のプロキシで接続をまとめる、という順で考えます。この記事では、その理由と具体的な手順を説明します（2026年10月時点の WordPress のソースコードと各ソフトの公式ドキュメントに基づきます）。
WordPress がデータベースに接続する仕組み
- WordPress は起動時に
wpdbクラスを作り、そこでmysqli_real_connect()を呼んで接続します。接続はそのリクエストの間だけ使われ、PHP の処理が終わると閉じられます。 - PHP-FPM の1つのプロセスは同時に1つのリクエストしか処理しないため、WordPress だけのサーバーなら、同時接続数はおおむね「動いている PHP-FPM のプロセス数」になります。
- オブジェクトキャッシュ（Redis など）を入れると問い合わせの回数は減りますが、WordPress は起動時に接続するため、接続の数そのものは減りません。PHP を通らずに返すページキャッシュは、そのぶん接続を減らします。
wp-config.php や php.ini で接続プールにできない理由
インターネット上には、wp-config.php に MYSQLI_USE_MYSQLND や WP_CACHE_KEY_SALT を書く、php.ini に mysqli.cache_size を書く、といった「接続プールの設定」が紹介されていることがあります。これらは接続プールの設定ではありません。
MYSQLI_USE_MYSQLNDという WordPress の設定は存在しません。WP_CACHE_KEY_SALTは、オブジェクトキャッシュのドロップインがキャッシュのキーの先頭に付ける文字列で、データベースの接続とは関係ありません。mysqli.cache_sizeは PHP の mysqli の設定一覧にありません。
PHP の mysqli には、ホスト名の前に p: を付けると「永続接続」になる機能があります（php.ini の mysqli.allow_persistent、mysqli.max_persistent で制御）。しかし WordPress の wpdb は DB_HOST を独自に解析してホスト名・ポート・ソケットに分けるため、define( 'DB_HOST', 'p:localhost' ); と書くと p という名前のホストに接続しようとして失敗します。WordPress 本体の設定だけで永続接続を使うことはできません。
なお、永続接続は PHP-FPM の各プロセスが接続を持ち続ける仕組みで、接続の総数はプロセス数と同じだけ常に使われます。接続を開く時間は省けますが、同時接続数を減らす効果はありません。
接続数を見積もって max_connections を合わせる
まずは接続数の上限を正しく決めるのが基本です。
今の状態を確認する
-- 接続数の上限（MySQL の既定値は 151）
SHOW VARIABLES LIKE 'max_connections';
-- 起動してからの最大同時接続数
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
-- 今の接続数
SHOW GLOBAL STATUS LIKE 'Threads_connected';Max_used_connections が max_connections に近いか同じなら、上限に達したことがあります。そのときアプリ側には「Too many connections」というエラーが出て、WordPress は「データベース接続確立エラー」を表示します。
見積もりの式
WordPress の Web サーバーが PHP-FPM の場合、PHP-FPM の設定（プールの設定ファイル）の pm.max_children が、そのサーバーから同時に張られる接続の上限の目安です。
; 例: /etc/php/8.3/fpm/pool.d/www.conf（パスはディストリビューションや PHP のバージョンで異なる）
pm = dynamic
pm.max_children = 20必要な max_connections は次のように見積もります。
- Web サーバー1台の
pm.max_children× Web サーバーの台数 - ＋ cron や WP-CLI、バックアップ、管理用の接続など
- ＋ 余裕（1〜2割程度）
たとえば pm.max_children = 20 の Web サーバーが3台なら、20 × 3 = 60 に cron などの分と余裕を足して、80〜100 程度を目安にします。max_connections だけを大きくしても、データベースサーバーのメモリや CPU が足りなければ処理は速くなりません。PHP-FPM の数を増やすときは、データベース側の負荷も合わせて確認します。
max_connections を変更する
VPS などで MySQL の設定を変更できる場合は、設定ファイルの [mysqld] に書き、再起動します。
[mysqld]
max_connections = 100再起動せずに変える場合は SET GLOBAL max_connections = 100; を使えますが、再起動すると元に戻るため、設定ファイルにも書いておきます。共用のレンタルサーバーやマネージドデータベースでは、利用者が変更できないか、管理画面から設定する形になっていることが多いため、各サービスの案内を確認します。
wait_timeout（使われていない接続を切るまでの秒数、既定値は 28800）は、WordPress のように処理が終わると接続を閉じる使い方ではあまり影響しません。値を大きくしても接続プールにはなりません。
ProxySQL を間に置いて接続をまとめる
Web サーバーの台数が多い、アクセスが急に増えるなどで、上の見積もりでは max_connections が足りなくなる場合は、WordPress とデータベースの間に ProxySQL を置きます。ProxySQL は、多数のクライアント接続を、少ない数のバックエンド接続で使い回す（多重化する）MySQL 用のプロキシです。WordPress から見ると、接続先が ProxySQL に変わるだけです。
設定の流れ
ProxySQL を Web サーバーと同じサーバー、または専用のサーバーに入れたら、管理用のインターフェース（既定ではポート 6032）に接続して設定します。既定の管理ユーザー（admin / admin）は、運用前に変更してください。
mysql -u admin -padmin -h 127.0.0.1 -P6032 --prompt 'ProxySQL Admin> 'データベース側には、ProxySQL が死活確認に使う監視用ユーザーを作ります（パスワードは置き換えてください）。
-- MySQL 側で実行
CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor_password';
GRANT USAGE, REPLICATION CLIENT ON *.* TO 'monitor'@'%';ProxySQL の管理インターフェースで、接続先のデータベース、監視用ユーザー、WordPress が使うユーザーを登録します。wp_user と wp_password は wp-config.php の DB_USER・DB_PASSWORD と同じものにします。
-- ProxySQL の管理インターフェースで実行
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '10.0.0.10', 3306);
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
UPDATE global_variables SET variable_value = 'monitor' WHERE variable_name = 'mysql-monitor_username';
UPDATE global_variables SET variable_value = 'monitor_password' WHERE variable_name = 'mysql-monitor_password';
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;
INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('wp_user', 'wp_password', 1);
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;ProxySQL の設定は「メモリ上の設定 → 実行中の設定（RUNTIME）→ ディスク（DISK）」の3層になっていて、LOAD ... TO RUNTIME で反映、SAVE ... TO DISK で再起動後も残るようにします。
WordPress の接続先を切り替える
アプリ用のポート（既定では 6033）に接続するよう、wp-config.php の DB_HOST を変えます。localhost と書くと mysqli は TCP ではなくソケットで接続しようとするため、同じサーバーの ProxySQL に接続するときは 127.0.0.1 とポート番号を書きます。
define( 'DB_HOST', '127.0.0.1:6033' );切り替えたら、サイトの表示・ログイン・記事の保存を確認し、ProxySQL 側で接続が流れていることを確かめます。
-- ProxySQL の管理インターフェースで、バックエンドごとの接続の使われ方を見る
SELECT hostgroup, srv_host, status, ConnUsed, ConnFree, ConnOK, ConnERR FROM stats_mysql_connection_pool;WordPress で使うときの注意
ProxySQL は、接続の状態を安全に使い回せないと判断したクエリがあると、その接続の多重化を止めます。公式ドキュメントでは、トランザクション中、LOCK TABLES、GET_LOCK()、@ を含むユーザー変数、SQL_CALC_FOUND_ROWS、一時テーブルの作成などが条件として挙げられています。WordPress の投稿一覧の取得（WP_Query）は、ページ送りのために SQL_CALC_FOUND_ROWS を使うことがあるため、期待したほど接続がまとまらない場合があります。導入の前に検証環境で、stats_mysql_connection_pool の数字を見ながら効果を確かめてください。
Amazon RDS / Aurora を使っている場合は、マネージドの RDS Proxy も同じ目的で使えます。
まとめ
- WordPress には接続プールの設定が無い。リクエストごとに接続し、終わると閉じる
MYSQLI_USE_MYSQLND、WP_CACHE_KEY_SALT、mysqli.cache_sizeは接続プールの設定ではない。DB_HOSTのp:も WordPress では使えない- まず
pm.max_children× Web サーバーの台数＋余裕でmax_connectionsを見積もり、Max_used_connectionsで確かめる - それでも足りない構成では ProxySQL（または RDS Proxy）を間に置き、
DB_HOSTを切り替える - ProxySQL は
SQL_CALC_FOUND_ROWSなどで多重化が止まるため、効果は検証環境で数字を見て判断する
関連記事: