加速（慢）巨大的wordpress数据库

Question

我正在测试一个新项目，其中涉及使用wordpress安装，其中有超过150万个帖子，通常帖子内容/标题只有一两行 - 所以很短。

我已经获得了强烈推荐的W3-cache插件，它有很多帮助 - 但是当你第一次登陆页面时，需要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
    )

无论上述问题如何，我都是在妈妈的共享主机上 - 显然它不会削减它，我想问的是，如果你在哪里运行这种类型的网站 - 什么样的服务器规格/托管计划你会考虑处理这种大小的安装吗？每周都会有几个游客开始向上移动。

Answer 1

1）在WAMP上使用mysqltuner（无法在没有root的情况下安装在共享主机上）来调优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'

然后优化所有表格。然后添加

define ('WP_POST_REVISIONS', FALSE);

靠近wp-config.php的顶部（在开放<?php ...之后的某个地方），以禁用将来的修订。

3）增加php和WP的内存以获得更好的性能：

将php.ini中的memory_limit行编辑为128M：

memory_limit = 128M;

或者在.htaccess文件的顶部添加此行：

php_value memory_limit 128M

如果这不起作用或抛出错误，请在打开<?php

之后立即在wp-config.php文件顶部附近添加此行

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

4）在最终的VPS上，配置http.conf以获得性能，并可能为MySQL服务器本身使用不同的框。

Answer 2

共享主机显然达到了性能极限。问题是硬件不足，而不是查询本身，所以你需要做的就是为自己买一台专用机器。这里的瓶颈似乎是MySQL，它通常是磁盘绑定的，但如果你的网站即将增长非常大，我会开始准备一些不同的架构，带有HTTP的负载平衡器和一台强大的MySQL机器（我认为i7有12台演出ram并不太贵，如果你要使用单片数据存储，我会将它用于MySQL服务器。）