2026年8月3日

WordPressのMySQL接続をUnixソケットに変更してパフォーマンスを改善する

サーバー・ホスティング

WordPress と MySQL（または MariaDB）が同じサーバーにあるなら、接続を TCP から Unix ソケットに切り替えると、TCP の処理やポートの消費を省けます。設定の中心は wp-config.php の DB_HOST で、多くの場合 localhost を指定するかソケットのパスを書くだけで切り替わります。この記事では、今どちらで接続しているかの確かめ方、ソケットのパスと MySQL ユーザーの確認、wp-config.php の書き方、つながらないときの原因と対処、効果の測り方を順に説明します。

Unix ソケット接続で何が変わるのか

TCP で 127.0.0.1 に接続すると、同じサーバー内の通信でも TCP のハンドシェイクやネットワークスタックの処理が入り、接続を閉じるたびに送信元ポートが TIME_WAIT として一定時間使われます。Unix ソケットはファイルシステム上の特殊なファイルを介してプロセス同士が直接やり取りする仕組みで、これらの処理を通りません。

ただし、効果の大きさは控えめに見積もってください。1回の接続やクエリで短縮できる時間はわずかで、アクセスが多い、1ページあたりのクエリが多い、といった条件で積み重なって効いてくるものです。遅いクエリやキャッシュ不足が原因の遅さは、接続方式を変えても解消しません。

また、Unix ソケットは同じサーバー（同じ OS）の中でしか使えません。Amazon RDS などのマネージド DB や、別の VPS に置いた DB サーバーには TCP で接続するしかありません。

今どちらで接続しているかを確かめる

まず wp-config.php の DB_HOST を確認します。WP-CLI が使えるなら次のコマンドで値を表示できます。

wp config get DB_HOST

値ごとの意味は次のとおりです。

localhost: PHP の MySQL 拡張（mysqli）は、ホスト名が localhost のとき通常 Unix ソケットで接続します。すでにソケット接続になっている可能性が高い状態です。
127.0.0.1 や 127.0.0.1:3306: IP アドレスを指定しているので TCP 接続です。
localhost:/パス: 指定したソケットファイルで接続します。

実際の接続方式は、WordPress の接続から MySQL に問い合わせると確かめられます。Unix ソケットの接続は host が localhost だけになり、TCP の接続は 127.0.0.1:52344 のようにポート番号が付きます。

wp eval 'global $wpdb; echo $wpdb->get_var( "SELECT host FROM information_schema.processlist WHERE id = CONNECTION_ID()" ), PHP_EOL;'

WP-CLI は PHP の CLI 版で動くため、Web サーバーで動いている PHP-FPM とは php.ini が別になっていることがあります。CLI ではソケットで接続できても、PHP-FPM では既定のソケットのパスが違う、ということが起こりうるので、切り替え後はブラウザでも動作を確認してください。

ソケットのパスを調べる

MySQL がどこにソケットを作っているかは、サーバー側の設定で確認します。

# Ubuntu などで root が auth_socket 認証の場合
sudo mysql -e "SHOW VARIABLES LIKE 'socket';"

# パスワード認証の管理ユーザーで確認する場合
mysql -u root -p -e "SHOW VARIABLES LIKE 'socket';"

よく見かけるパスは、Debian・Ubuntu 系の /run/mysqld/mysqld.sock（/var/run/mysqld/mysqld.sock も同じ場所を指すことが多い）、RHEL 系の /var/lib/mysql/mysql.sock です。ただし、パッケージの入手元やバージョン、my.cnf の設定で変わるため、上のコマンドで確かめた値を使ってください（2026年10月現在）。

次に、PHP が既定で使うソケットのパスを確認します。

php -i | grep -i default_socket

mysqli.default_socket が空なら PHP をビルドしたときの既定値が使われ、MySQL 側のパスと一致しないことがあります。一致しない場合は、後述のように wp-config.php でパスを明示するのが手軽です。

MySQL ユーザーのホスト指定を確認する

見落としやすいのが、MySQL ユーザーのホスト部分です。Unix ソケットでの接続は 'ユーザー名'@'localhost' のアカウントとして扱われます。WordPress 用のユーザーを 'wp_user'@'127.0.0.1' だけで作っていると、ソケットに切り替えた途端に認証エラーになります。

-- WordPress 用ユーザーのホストと認証方式を確認
SELECT user, host, plugin FROM mysql.user WHERE user = 'wp_user';

-- 既存の権限を確認（localhost 用を作るときの参考にする）
SHOW GRANTS FOR 'wp_user'@'127.0.0.1';

localhost のアカウントがない場合は、既存アカウントと同じ権限で作成します。パスワードは推測されにくいものを使い、コマンド履歴やログに残らない方法で入力してください。

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP ON wordpress.* TO 'wp_user'@'localhost';

付与する権限は、SHOW GRANTS で確認した既存アカウントの内容に合わせます。また、WordPress 用ユーザーは通常どおりパスワード認証のままにしておきます。MySQL の auth_socket（MariaDB では unix_socket）は OS のユーザー名で認証する方式で、管理用の root では便利ですが、WordPress 用に使うと PHP-FPM の実行ユーザーと結びつき、バックアップツールなど他の接続に影響が出ます。

wp-config.php を書き換える

作業の前に wp-config.php をバックアップします。書き方は2通りです。

// 方法1: PHP の既定のソケットを使う
define( 'DB_HOST', 'localhost' );

// 方法2: ソケットのパスを明示する（どちらか一方だけを書く）
define( 'DB_HOST', 'localhost:/run/mysqld/mysqld.sock' );

方法2の ホスト:/パス という書き方は、WordPress が DB_HOST を分解して mysqli に渡す処理（4.9 以降の wpdb::parse_db_host()）が解釈します。ホスト部分は localhost にしてください。127.0.0.1:/パス のように IP アドレスを書くと、mysqli はソケットではなく TCP で接続しようとします。

書き換えたら、トップページ、管理画面へのログイン、投稿の保存を試し、前の章の確認コマンドで host がポート番号なしの localhost になっていることを確かめます。

つながらないときの原因と確認方法

切り替え後に「データベース接続確立エラー」が表示されたら、すぐに wp-config.php を元に戻してサイトを復旧させてから原因を調べます。ステージングで再現させ、wp-config.php で WP_DEBUG と WP_DEBUG_LOG を有効にすると、wp-content/debug.log や PHP のエラーログに mysqli のエラーが記録されます。可能性の高い順に確認します。

ソケットのパスが違う: No such file or directory を含むエラー（エラー番号 2002）が出ます。SHOW VARIABLES LIKE 'socket' の値と DB_HOST のパスを照らし合わせ、方法2でパスを明示します。
ユーザーのホストが合わない: Access denied for user 'wp_user'@'localhost'（エラー番号 1045）が出ます。前の章の手順で localhost のアカウントを用意します。
ソケットに接続する権限がない: Permission denied を含むエラーが出ます。ls -ld /run/mysqld と ls -l でソケットのディレクトリとファイルの権限を確認し、PHP-FPM の実行ユーザーが読み書きできるかを見ます。RHEL 系で SELinux が有効なら、監査ログに拒否の記録がないかも確認します。
PHP-FPM から /tmp が見えていない: ソケットを /tmp に置いている構成で、PHP-FPM の systemd ユニットが PrivateTmp=true になっていると、PHP-FPM からはそのソケットが見えません。ソケットを /run/mysqld などに移すのが素直な対処です。
DB が別のコンテナにある: Docker などで WordPress と DB を別コンテナに分けている場合、ソケットファイルを共有ボリュームで渡さない限りソケット接続はできません。コンテナ間はそのまま TCP で接続するのが一般的です。

効果の測り方

切り替えの効果は、ステージングで同じ条件のまま比較します。ページキャッシュを無効にした状態で、クエリの多いページ（アーカイブ、検索結果、商品一覧など）に同じ負荷をかけ、応答時間を比べます。Query Monitor プラグインを使うと、ページごとのクエリ数とクエリにかかった時間を確認できます。

差がほとんど出なくても、それは異常ではありません。その場合は、遅いクエリの改善、オブジェクトキャッシュの導入、MySQL のメモリ設定の見直しのほうが効果が大きいはずです。

合わせて検討したい設定

WordPress を含め、MySQL を使うアプリケーションがすべてソケットで接続するようになったら、MySQL の TCP 待ち受けを絞ると攻撃面を減らせます。my.cnf で bind-address = 127.0.0.1 にすると外部からの TCP 接続を受け付けなくなり、skip-networking にすると TCP の待ち受け自体を止められます。

ただし、phpMyAdmin、バックアップツール、監視エージェント、別コンテナのアプリケーションなどが TCP で接続していると、それらが使えなくなります。変更の前に ss -tnp | grep 3306 などで TCP 接続している相手を洗い出し、ステージングで確かめてから本番に適用してください。外部からの 3306 番ポートへの接続は、MySQL の設定に関係なくファイアウォールでも閉じておくのが基本です。

まとめ

DB が同じサーバーにあるなら、Unix ソケット接続で TCP の処理とポートの消費を省ける。効果は控えめで、遅いクエリの代わりにはならない
DB_HOST が localhost なら多くの場合すでにソケット接続。実際の方式は接続元の host にポート番号が付くかで確かめる
ソケットのパスは SHOW VARIABLES LIKE 'socket' で確認し、PHP 側の mysqli.default_socket と合わなければ localhost:/パス で明示する
ソケット接続は 'ユーザー'@'localhost' として認証されるため、アカウントのホスト指定を先に確認する
つながらないときは、パス・ユーザーのホスト・権限・PrivateTmp・コンテナ構成の順に確認する
wp-config.php はバックアップしてから変更し、ステージングで効果を測る