web-dev-qa-db-ja.com

どうして `wp_options`テーブルは` autoload`のインデックスを持っていないのですか？

WordPressによって提供される各ページの始めに、オプションを取得するためのMySQL呼び出しがあります。

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

autoload列にはインデックスがないため、MySQLはすべての行を検索する必要があります。

この答え インデックスがあってもパフォーマンスの向上はないと言っているというコメントにも出会いました。

私のアプリケーションでは、セッションの置き換えとして役立つ一時的な値を多数使用しました。それらは素晴らしい働きをし、私は私自身のガベージコレクションルーチンを持っています。 wp_optionsテーブルでは、私の一時的な値（_transient_で始まるもの）はすべてautoload=noを持っています。同時ユーザー数が増えると、wp_optionsテーブルの行数が増えることが予想されます。

テーブルがこのように設計されている理由を知りたいのですが。そして私は私の特定のケースのためにインデックスを作成すべきですか？

plugin-developmentwp-options
15
He Shiming

必要性が十分に強くなかったので、インデックスはありません。

チケット＃14258 で提案されていますが、ほとんどのオプションはデフォルトでautoload=yesを使っているので、とにかくインデックスは無視されます。

まだ公開されているチケットもあります ＃24044 _パフォーマンスを向上させるためのwp_optionsへのインデックスの追加_ 。

私はあなたがインデックスを作成するべきだと思います。それはアップグレードを生き残るでしょう。パフォーマンスには役立たないかもしれませんが、実際の統計データをそのチケットに追加することはできます。

11
fuxia

私はDebian Squeezeの大きなインスタンスで3 WPブログを運営していて、なぜmysqlが200％のCPU使用率と3から6の間のシステム負荷でそのホストで動けなくなったのか調査していました。 MySQL内部では、wp_optionテーブルがこの問題に関係していることがわかったので、以下を実行しました。

alter table wp_options add index autoload_idx(`autoload`);

この操作の後、上に表示されているmysqlの負荷は劇的に1％に低下し、インスタンスの平均負荷は0.10になりました。

私たちはいくつかのプラグインを使っているのでコードのどこかにループがあるかもしれません、そしてこれは特別な状況かもしれませんが、私たちの場合パフォーマンスの変化は全く驚くべきものです。

Wp_optionsテーブルには347行あります。

5
Fabio Pedrazzoli