加快A（慢）巨大的WordPress數據庫

Question

我測試了一個新的項目，涉及使用其中有超過150萬的職位，一般的帖子內容的WordPress安裝的/標題只有一兩行 - 所以相當短。

我已經得到了強烈建議W3緩存插件，它幫助了很多 - 但是當你在頁面上第一土地它需要一個良好的40-60加載和生成它的緩存，並配有現場其中包含超過100萬的帖子，我猜他們所有的緩存將會是一場災難 - 因爲只有約5％會被定期查看。

下面是發生了什麼事情一個職位的標準版本，是有什麼我可以做些什麼來改變/加速明顯的瓶頸？我甚至不確定JOIN在做什麼？當然，所有需要發生的事情都是通過ID發帖。需要這麼長時間的查詢看起來像是一個顯示大量帖子並根據元數據排序的查詢 - 我在帖子頁面上不需要這些查詢？

[5] => Array 
    (
     [0] => SELECT wp_posts.* FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') AND (wp_postmeta.meta_key = 'wpfp_favorites') GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value+0 ASC LIMIT 0, 1 
     [1] => 43.2097918987 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, start_post_rel_link, get_boundary_post_rel_link, get_boundary_post, get_posts, WP_Query->query, WP_Query->get_posts, W3_Db->query 
    ) 

[6] => Array 
    (
     [0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date < '0000-00-00 00:00:00' AND p.post_type = 'post' AND p.post_status = 'publish' ORDER BY p.post_date DESC LIMIT 1 
     [1] => 7.29560852051E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post, W3_Db->query 
    ) 

[7] => Array 
    (
     [0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date > '0000-00-00 00:00:00' AND p.post_type = 'post' AND p.post_status = 'publish' ORDER BY p.post_date ASC LIMIT 1 
     [1] => 1.78813934326E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post, W3_Db->query 
    ) 

[8] => Array 
    (
     [0] => SELECT option_value FROM wp_options WHERE option_name = 'theme_mods_twentyeleven' LIMIT 1 
     [1] => 1.00135803223E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, _custom_background_cb, get_background_image, get_theme_mod, get_theme_mods, get_option, W3_Db->query 
    ) 

[9] => Array 
    (
     [0] => SELECT option_value FROM wp_options WHERE option_name = 'mods_Twenty Eleven' LIMIT 1 
     [1] => 8.82148742676E-6 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, _custom_background_cb, get_background_image, get_theme_mod, get_theme_mods, get_option, W3_Db->query 
    ) 

[10] => Array 
    (
     [0] => SELECT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('post_format') AND tr.object_id IN (1034759) ORDER BY t.name ASC 
     [1] => 1.31130218506E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, body_class, get_body_class, get_post_format, get_the_terms, wp_get_object_terms, W3_Db->query 
    ) 

[11] => Array 
    (
     [0] => SELECT DISTINCT post_author FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish' LIMIT 2 
     [1] => 1.31130218506E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, body_class, get_body_class, apply_filters, call_user_func_array, twentyeleven_body_classes, is_multi_author, W3_Db->query 
    ) 

[12] => Array 
    (
     [0] => SELECT * FROM wp_posts WHERE (post_type = 'page' AND post_status = 'publish') AND (ID <> 1232798) ORDER BY menu_order,wp_posts.post_title ASC 
     [1] => 1.00135803223E-5 
     [2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_nav_menu, call_user_func, wp_page_menu, wp_list_pages, get_pages, W3_Db->query 
    ) 

[13] => Array 
    (
     [0] => SELECT * FROM wp_users WHERE ID = 4031 LIMIT 1 
     [1] => 2.00271606445E-5 
     [2] => require, require_once, include, the_post, WP_Query->the_post, setup_postdata, get_userdata, W3_Db->query 
    ) 

[14] => Array 
    (
     [0] => SELECT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('post_tag') AND tr.object_id IN (1034759) ORDER BY t.name ASC 
     [1] => 1.78813934326E-5 
     [2] => require, require_once, include, get_template_part, locate_template, load_template, require, post_class, get_post_class, get_the_tags, get_the_terms, wp_get_object_terms, W3_Db->query 
    ) 

[15] => Array 
    (
     [0] => SELECT * FROM wp_comments WHERE comment_approved = '1' AND comment_post_ID = 1034759 ORDER BY comment_date_gmt ASC 
     [1] => 2.09808349609E-5 
     [2] => require, require_once, include, comments_template, get_comments, WP_Comment_Query->query, W3_Db->query 
    ) 

[16] => Array 
    (
     [0] => SELECT post_id, meta_value, post_status FROM wp_postmeta LEFT JOIN wp_posts ON post_id=wp_posts.ID WHERE post_status='publish' AND meta_key='wpfp_favorites' AND meta_value > 0 ORDER BY ROUND(meta_value) DESC LIMIT 0, 5 
     [1] => 1.50203704834E-5 
     [2] => require, require_once, include, get_sidebar, locate_template, load_template, require_once, dynamic_sidebar, call_user_func_array, wpfp_widget_view, wpfp_list_most_favorited, W3_Db->query 
    ) 

不管對上述問題的，我就在momment共享主機 - 這樣顯然它不會削減它，我想問的是，如果你在哪裏運行這類網站 - 什麼樣的服務器規格/託管計劃，你會看着處理這種大小的安裝？每週有幾位遊手開始上升。

Answer 1

共享主機顯然達到了性能極限。問題在於硬件不足，而不是查詢本身，所以你需要做的是爲自己準備一臺專用機器。這裏的瓶頸似乎是MySQL，它通常是磁盤綁定的，但是如果你的網站將要變得非常龐大，我會開始準備一些與HTTP負載平衡器和MySQL強大的機器有些不同的體系結構（我認爲i7有12個演出內存不是太昂貴，如果你打算使用單片數據存儲，我會使用它的MySQL服務器）。

Answer 2

1）WAMP使用mysqltuner（你不能在共享主機無根）調整MySQL和改變查詢緩存，內存等將就WAMP和最終直播服務器的巨大差異安裝。 https://github.com/rackerhacker/MySQLTuner-perl

2）請務必從數據庫中刪除後/頁的修訂。 WP可以存儲大量影響數據庫速度的修訂版本。刪除帖子/頁面修訂後，我看到數據庫大小下降了90％。

運行在phpMyAdmin來刪除修改SQL查詢;根據需要更改表前綴：

DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision'

然後優化所有表。然後停用日後的版本（開<?php ...後某處）添加

define ('WP_POST_REVISIONS', FALSE);

附近的wp-config.php文件的頂部。

3）加大對PHP和WP內存有更好的表現：

編輯在php.ini中memory_limit的線路爲128M：

memory_limit = 128M;

或者在頂部添加這一行你。htaccess文件：

php_value memory_limit 128M

如果不工作或引發錯誤，開幕<?php

define('WP_MEMORY_LIMIT', '128M');

之後添加靠近你的wp-config.php文件的頂部這一行

4）在最終的VPS上，配置http.conf的性能，並可能爲MySQL服務器本身使用不同的方框。