私は非常に大きなデータベースをテストしています(おそらくwp_posts
には何十万もの行が含まれています)。そのため、クエリ時間、特に検索クエリは非常に長くなります。元のデータベースと比較してurl構造が変更されないように、WPデータベースをテーブルプレフィックスの異なる複数のテーブルに分割する方法が他にあるかどうかを考えています。
$table_prefix
のwp_config
をwpa_
に変更してみたところ、投稿名がa
で始まるサンプル投稿が作成されました。それから私は$table_prefix
のwp_config
をwpb_
に変更し、それから私はポスト名がb
で始まるサンプル投稿を作成しました。
次のステップで、$table_prefix
行を次の行に置き換えます。
// if query for post start with a, it will go to wpa_ tables,
// if query for post start with b, it will go to wpb_ tables
$prefix = get_the_title();
if ($prefix(0) !== 'a') {
$table_prefix = 'wpb_';
} else {
$table_prefix = 'wpa_';
}
ドメインを開こうとすると、エラーFatal error: Call to undefined function get_the_title() in /home/todaytra/public_html/1/wp-config.php on line 62
が発生しました
私は本当にこのタスクを実行する必要があります、通常のWPMUインストールはサブドメインかサブフォルダーのどちらかを生成します、そしてそれはすべての投稿のパーマリンク構造を変えます。私はたくさん検索してみましたが、これに関する情報を見つけることができませんでした。
パム、
それはあなたがいくつかの大きな課題に直面しているように聞こえますが、私はテーブルプレフィックスをめちゃくちゃにしないことを強くお勧めします。そうすることは一連の問題を引き起こすでしょう、それはWordPressインストールのかなりの混乱であなたを残してハックの後にハックを必要とするでしょう。
遅いクエリの問題を解決するためにできることが他にもあります。これらすべてが必ずしも簡単なわけではありませんが、テーブルプレフィックスをハックしようとするよりもあなたの時間の価値があります。
1)あなたがWP 3.4+にいることを確認してください。 3.4では標準クエリにNiceの改善がいくつかあり、クエリの速度が向上しました。
2)特に問題のあるクエリでは、no_found_rows
をtrue
に、update_post_term_cache
をfalse
に、およびupdate_post_meta_cache
をfalse
に設定することを検討してください。これらはすべてクエリパフォーマンスの向上につながりますが、影響を理解するためにある程度の時間を費やす必要があります。コーデックスでそれらについて読んでください: http://codex.wordpress.org/Class_Reference/WP_Query
3)クエリのキャッシュを提供するために永続オブジェクトキャッシュを使用します。これは間違いなくより複雑なプロセスですが、高価なクエリをRAMまたはディスクにキャッシュすることで、繰り返しの遅いクエリを節約できます。
4)ページキャッシュをインストールします( WPスーパーキャッシュ はこれをうまく行います)。これは、高価なクエリが呼び出される回数を減らすのに役立ちます。これはクエリの問題を直接解決するものではありません。ただし、クエリが呼び出される可能性がある回数が少なくなります。
最初の提案を超えて、私はこれらのどれもが「簡単」であるとは考えていません。しかし、あなたが私たちの考えではあなたがすることを提案することは巨大な無駄であり、あなたの時間はWordPressで遅い問い合わせに対処するための代替オプションを調査するためによりよく費やされるでしょう。あなたはWordPress、拡張性の問題、そして標準的なWordPressのやり方で物事を行うためのより良い方法についてもっと学ぶでしょう。