なぜ `wp_options`テーブルには` autoload`のインデックスがありませんか?


15

WordPressが提供する各ページの先頭には、オプションを取得するMySQL呼び出しがあります。

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

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

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

私のアプリケーションでは、多くの一時的な値を使用して、セッションの代替として機能しました。それらは素晴らしく機能し、私には独自のガベージコレクションルーチンがあります。wp_options表では、一時的な値(で始まる値_transient_)がすべてになっていることに気付きましたautoload=nowp_options同時ユーザーの数が増えると、テーブルの行数が増えると思います。

テーブルがこのように設計されている理由を知りたい。また、特定のケースのインデックスを作成する必要がありますか?

回答:


11

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

チケット#14258それが示唆されたが、ほとんどのオプションは使用しているためautoload=yes、デフォルトでは、インデックスはとにかく無視されます。

まだオープンチケット#24044 _wp_optionsにインデックスを追加してパフォーマンスを支援/改善します_もあります

インデックスを作成する必要があると思います。アップグレード後も存続します。パフォーマンスを改善することはできませんが、実際の統計データをそのチケットに追加することはできます。


2019年11月に更新

インデックスがWordPress 5.3に追加されました。最後に。上記のチケット#24044とリリースの開発者向けメモを参照してください。

同じ名前の既存のインデックスがある場合、アップグレード中に警告が表示されることに注意してください。

変更セットから:

ほとんどのサイトはこの変更の影響を受けませんが、に多数の行wp_optionsautoload設定されているサイトでは、設定されているのはごく少数ですが、パフォーマンスが大幅に向上します。
に多数の行wp_optionsautoload設定されているサイトでは、残念ながら、実行中の既に非常に遅いクエリに加えてパフォーマンスの低下が見られますが、これは少数のケースです。


1
#24044を読んでわかる限り、古いMyISAMテーブルはパフォーマンスの低下を招き、新しいInnoDBテーブルはほとんど利益を得るでしょう。すべてのレガシーテーブルをInnoDBに変換し、autoload列にインデックスを設定しています。
lkraav

長い年月を経て、ついにWordPressチームによって対処されました。にインデックスが追加されましたwp_options.autoload。ソース:make.wordpress.org/core/2019/10/15/… ...および... core.trac.wordpress.org/ticket/24044#comment:87 ... この機能を提案した@DanBUKへの称賛 2013
。– Jee

ありがとう、@ Jee、答えを更新しました。
fuxia

5

私はDebian Squeezeラージインスタンスで3つのWPブログを実行しており、mysqlが200%のCPU使用率と3〜6のシステム負荷でそのホストでスタックする理由を調査していました。mysql内の「show process list」を見ると、 wp_optionテーブルがこの問題に関与していたため、次を実行しました。

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

この操作の後、上の図に示すmysqlの負荷は大幅に1%に低下し、インスタンスの負荷平均は0.10になりました。

プラグインを使用しているため、コードのどこかにループが発生する可能性があり、これは特定の状況かもしれませんが、パフォーマンスの変化は驚くべきものです。

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


2
共有してくれてありがとう。WordPressにはこのオプションテーブルの処理に欠陥があると考えました。非常に小さいため、クエリを実行しないでください。select *一度だけであるべきです。代わりに、各オプションを照会するため、インデックスを配置すると大きな違いが生じます。
彼は

0

しばらく@fuxia 受け入れ答えのいくつかの「主張」の理由に触れ(ほとんどが様々なTracのチケットなどのオートマティックの従業員が主張していた)、根本的な理由内の自動ロードオプションのインデックスを含まないWordPressのコア用wp_optionsのテーブルがあるということですAutomatticは、MyISAMエンジンをまだ使用しているMySQLデータベースのパフォーマンスに悪影響を及ぼすと心配していました。

具体的には、このようなインデックスによってパフォーマンスが低下するWebサイトの例として、非常に古い/複雑なデータベースであるWordPress.org Webサイト自体を示しました。

過去9年間インデックスを追加しなかった他のほぼすべての理由(はい、Tracチケット#14258の場合は2010年から、Tracチケット#24044の場合は2013年以降)は、 WordPressコミュニティ、しかし関係するAutomatticの従業員は、いくつかの独立したベンチマークテストを繰り返し無視し、MyISAMの懸念に言及するように戻った。

ありがたいことに、2019年後半には、PHP 7.2で WordPress Coreが推奨する「デフォルト」バージョンになり、InnoDBエンジンでは、5.5以降MySQLバージョンでデフォルトになりましたなり、何年も問題にとどまった@DanBUKを含むさまざまな開発者からの継続的なプレッシャーがありました、Automatticはついに譲歩し、2019年11月にWordPress 5.3以降でautoloadインデックスを追加することにしました。

LittleBizzy では、インデックスが存在しない場合に自動的にインデックスを追加する最初のプラグインを開始しました。このプラグインはGitHubで引き続き利用可能であり、定期的にダウンロードされます。WP Core 5.3以降を実行している場合、WordPressスタックにそのようなプラグインをインストールする必要はもうないことに注意してください...

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.