資訊專欄INFORMATION COLUMN
摘要：網站網站數據，數據庫查詢優化數據庫查詢優化。如果用命令速度會快很多，因為用并不真正執行查詢，而是查詢優化器估算的行數。則會在中有一行，不會拿到函數估算值。
WordPress網站10W+數據，mysql數據庫查詢優化。WordPress在查詢post列表時，默認會同時把文章數量也查詢出來，使用這種方式的有：get_posts 、query_posts和WP_Query。get_posts在4.6.1+已經不用SQL_CALC_FOUND_ROWS，但是query_posts和WP_Query還是會用，所以還須優化。
具體語句如下：
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = ‘post’ AND (wp_posts.post_status = ‘publish’ ) ORDER BY wp_posts.post_date DESC LIMIT 0, 20
SELECT FOUND_ROWS()
這在網站數據量小的時候，不會引起什么問題，
但是當post數量到10w+的時候，這個就是一條必現的慢查詢，
首頁、分類、標簽、搜索頁面，只要用到這幾個函數，就都會使用SQL_CALC_FOUND_ROWS這個方式。
如何解決?
方法一：
徹底禁用SQL_CALC_FOUND_ROWS
放在functions.php文件即可：
add_action(‘pre_get_posts’, ‘wndt_post_filter’);
function wndt_post_filter($query) {
if (is_admin() or !$query->is_main_query()) {
return $query;
}
// 禁止查詢 SQL_CALC_FOUND_ROWS
$query->set(‘no_found_rows’, true);
}
方法二：
如果仍然需要查詢文章數量，使用更加高效的EXPLAIN方式代替SQL_CALC_FOUND_ROWS
禁用掉SQL_CALC_FOUND_ROWS用法，用一種更加高效的方式，
這里我們用EXPLAIN方式
具體代碼如下，放在functions.php文件即可：
if ( ! function_exists( ‘maizi_set_no_found_rows’ ) ) {
/**
* 設置WP_Query的 ‘no_found_rows’ 屬性為true，禁用SQL_CALC_FOUND_ROWS
*
* @param WP_Query $wp_query WP_Query實例
* @return void
*/
function maizi_set_no_found_rows(/WP_Query $wp_query)
{
$wp_query->set(‘no_found_rows’, true);
}
}
add_filter( ‘pre_get_posts’, ‘maizi_set_no_found_rows’, 10, 1 );
if ( ! function_exists( ‘maizi_set_found_posts’ ) ) {
/**
* 使用 EXPLAIN 方式重構
*/
function maizi_set_found_posts($clauses, /WP_Query $wp_query)
{
// Don’t proceed if it’s a singular page.
if ($wp_query->is_singular()) {
return $clauses;
}
global $wpdb;
$where = isset($clauses[‘where’]) ? $clauses[‘where’] : ”;
$join = isset($clauses[‘join’]) ? $clauses[‘join’] : ”;
$distinct = isset($clauses[‘distinct’]) ? $clauses[‘distinct’] : ”;
$wp_query->found_posts = (int)$wpdb->get_row(“EXPLAIN SELECT $distinct * FROM {$wpdb->posts} $join WHERE 1=1 $where”)–>rows;
$posts_per_page = (!empty($wp_query->query_vars[‘posts_per_page’]) ? absint($wp_query->query_vars[‘posts_per_page’]) : absint(get_option(‘posts_per_page’)));
$wp_query->max_num_pages = ceil($wp_query->found_posts / $posts_per_page);
return $clauses;
}
}
add_filter( ‘posts_clauses’, ‘maizi_set_found_posts’, 10, 2 );
為什么用EXPLAIN而不是count(*)?
select count(*)是MySQL中用于統計記錄行數最常用的方法。
count方法可以返回表內精確的行數，每執行一次都會進行一次全表掃描，
以避免由于其他連接進行delete和insert引起結果不精確。
在某些索引下是好事，但是如果表中有主鍵，count(*)的速度就會很慢，特別在千萬記錄以上的大表。
如果用 explain 命令速度會快很多，因為 explain 用并不真正執行查詢，而是查詢優化器【估算】的行數。
在一個1500萬條記錄的表中測試，用select count(*)耗時15s，而用explain耗時0.08秒，
兩者相差差不多有200倍之多(第一次執行會稍慢，3秒左右)。
如下是explain方式：
mysql> explain select * from posts;
+—-+————-+————-+————+——+—————+——+———+——+———-+———-+——-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+————-+————+——+—————+——+———+——+———-+———-+——-+
| 1 | SIMPLE | posts | NULL | ALL | NULL | NULL | NULL | NULL | 12596096 | 100.00 | NULL |
+—-+————-+————-+————+——+—————+——+———+——+———-+———-+——-+
1 row in set, 1 warning (0.08 sec)
注意，這里用的是select *，不是select count(*)。
select *會返回一行數據，包括估算行數rows，在PHP中我們fetch()，再通過$result[‘rows’]就可以拿到這個預估值。
select count(*)則會在extra中有一行Select tables optimized away，不會拿到函數估算值。
所以，在對數據準確性要求不高，但是對速度要求很苛刻的場合，絕對有必要用這個估算值代替。
你也可以用下面這句，結果和explain一模一樣：
select TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES where TABLE_NAME=‘posts’;
+————+
| TABLE_ROWS |
+————+
| 12596096 |
+————+
1 row in set (0.04 sec)
根據實際情況任選一個，都是同一個東西。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/118229.html
wordpress數據庫優化和修復一般方法還是比較多的，有的用戶可能會安裝wordpress數據庫優化插件，比如：wp-optimize、wp_clean_up、WP-Sweep等優化插件。其實，我們也可以不用插件就能優化wordpress的mysql數據庫，比如使用官方推薦的工具，那么如何打開使用這個工具呢?官方自帶的數據庫修復和優化工具，也是首先針對MySQL。(MariaDB上也可以跑WP)...
摘要：數據庫怎么優化數據表是搭建程序中用來存儲文件附帶信息的，一般沒什么特別的情況，這些信息都是沒有什么作用的，下面分享一下優化優化教程，讓你的數據表變得更干凈，減少網站數據庫的負擔。請各位站長操作之前請先備份網站數據庫。wordpress數據庫怎么優化?wp_postmeta數據表是wordpress搭建程序中用來存儲文件附帶信息的，一般沒什么特別的情況，這些信息都是沒有什么作用的，下面分享一下...
摘要：網站數據，數據庫查詢優化。如果用命令速度會快很多，因為用并不真正執行查詢，而是查詢優化器估算的行數。則會在中有一行，不會拿到函數估算值。所以，在對數據準確性要求不高，但是對速度要求很苛刻的場合，絕對有必要用這個估算值代替。 WordPress網站10W+數據，數據庫查詢優化。 WordPress在查詢post列表時，默認會同時把文章數量也查詢出來，...
摘要：注意本文是我們的性能分析系列的第三篇，點此閱讀性能分析第一篇介紹，或性能分析第二篇深入研究。小的性能提升很可能來自優化，而非緩存。注意此更改已提交到并已獲更新。目前，兩者具備相同的特性，只有一些部分重命名了。 注意:本文是我們的 PHP 性能分析系列的第三篇，點此閱讀?PHP 性能分析第一篇: XHProf & XHGui 介紹?，或??PHP 性能分析第二篇: 深入研究 XHGui...
閱讀 730·2023-04-25 19:43
閱讀 3974·2021-11-30 14:52
閱讀 3800·2021-11-30 14:52
閱讀 3865·2021-11-29 11:00
閱讀 3796·2021-11-29 11:00
閱讀 3894·2021-11-29 11:00
閱讀 3571·2021-11-29 11:00
閱讀 6154·2021-11-29 11:00
