Идеи для оптимизации этих SQL-запросов

Question

Я использую плагин feedwordpress WordPress.

Он использует запросы, которые ОЧЕНЬ тяжелы на моем сервере, и я не уверен, как (или если) они могут быть улучшены. Bellow - это результат, который я получил от своей хостинговой компании, есть ли надежда на улучшение этого?

(извините за не более конкретным вопросом, но я не знаю, как - не стесняйтесь редактировать вопрос для того, чтобы улучшить его - спасибо)

most memory usage likely comes from the MySQL service: 
Uptime: 3 hours 32 min 48 sec 

Threads: 4 Questions: 761936 Slow queries: 254 Opens: 610 Flush tables: 1 Open tables: 603 Queries per second avg: 59.675 

It is up 3 and a half hour and already had more than 250 slow queries, I will list the last few queries, and once you manage to optimize these I'm sure the memory usage will decrease as well: 
# User@Host: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 5737 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 11.448474 Lock_time: 0.000059 Rows_sent: 0 Rows_examined: 66004 Rows_affected: 0 Rows_read: 66004 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 25335B6 
SET timestamp=1366020031; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# Time: 130415 5:01:01 
# User@Host: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 5785 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 4.344107 Lock_time: 0.000129 Rows_sent: 2219 Rows_examined: 13192 Rows_affected: 0 Rows_read: 13192 
# Bytes_sent: 23262206 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 25335D9 
SET timestamp=1366020061; 
SELECT wp_rb_posts.* FROM wp_rb_posts WHERE 1=1 AND (((wp_rb_posts.post_title LIKE '%git%') OR (wp_rb_posts.post_content LIKE '%git%'))) AND (wp_rb_posts.post_password = '') AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC; 
# Time: 130415 6:03:28 
# User@Host: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 8619 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 7.299722 Lock_time: 0.000092 Rows_sent: 0 Rows_examined: 66005 Rows_affected: 0 Rows_read: 66005 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 2534534 
SET timestamp=1366023808; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# User@Host: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 8620 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 9.666021 Lock_time: 0.000037 Rows_sent: 0 Rows_examined: 66005 Rows_affected: 0 Rows_read: 66005 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 2534533 
SET timestamp=1366023808; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# Time: 130415 6:58:25 
# User@Host: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 11340 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 4.616263 Lock_time: 0.000067 Rows_sent: 10 Rows_examined: 6014 Rows_affected: 0 Rows_read: 6014 
# Bytes_sent: 189 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 253530A 
SET timestamp=1366027105; 
SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID FROM wp_rb_posts WHERE 1=1 AND (wp_rb_posts.post_author = 56) AND wp_rb_posts.post_type = 'post' AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC LIMIT 0, 10; 

Вот результат для SHOW CREATE TABLE wp_rb_posts:

CREATE TABLE `wp_rb_posts` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT, 
`post_author` bigint(20) unsigned NOT NULL DEFAULT '0', 
`post_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_content` longtext NOT NULL, 
`post_title` text NOT NULL, 
`post_excerpt` text NOT NULL, 
`post_status` varchar(20) NOT NULL DEFAULT 'publish', 
`comment_status` varchar(20) NOT NULL DEFAULT 'open', 
`ping_status` varchar(20) NOT NULL DEFAULT 'open', 
`post_password` varchar(20) NOT NULL DEFAULT '', 
`post_name` varchar(200) NOT NULL DEFAULT '', 
`to_ping` text NOT NULL, 
`pinged` text NOT NULL, 
`post_modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_modified_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_content_filtered` longtext NOT NULL, 
`post_parent` bigint(20) unsigned NOT NULL DEFAULT '0', 
`guid` varchar(255) NOT NULL DEFAULT '', 
`menu_order` int(11) NOT NULL DEFAULT '0', 
`post_type` varchar(20) NOT NULL DEFAULT 'post', 
`post_mime_type` varchar(100) NOT NULL DEFAULT '', 
`comment_count` bigint(20) NOT NULL DEFAULT '0', 
PRIMARY KEY (`ID`), 
KEY `post_name` (`post_name`), 
KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`), 
KEY `post_parent` (`post_parent`), 
KEY `wp_rb_posts_guid_idx` (`guid`), 
KEY `post_author` (`post_author`), 
KEY `guid` (`guid`) 
) ENGINE=InnoDB AUTO_INCREMENT=69681 DEFAULT CHARSET=utf8 

следующий диагностический цикл был:

EXPLAIN SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID 
FROM wp_rb_posts 
WHERE 1 =1 
AND (
wp_rb_posts.post_author =56 
) 
AND wp_rb_posts.post_type = 'post' 
AND (
wp_rb_posts.post_status = 'publish' 
) 
ORDER BY wp_rb_posts.post_date DESC 
LIMIT 0 , 10 

с ВОЛП Выход мычание:

id select_type table type possible_keys key key_len ref rows Extra 
1 SIMPLE wp_rb_posts ref type_status_date,post_author post_author 8 const 5624 Using where; Using filesort 

Answer 1

Есть несколько пакетов для Linux, которые могут помочь вам диагностировать и настраивать сервер MySQL, а именно:

• innotop
• mysqltuner
• тюнинг-праймер

Answer 2

SELECT wp_rb_posts.* FROM wp_rb_posts WHERE 1=1 AND (((wp_rb_posts.post_title LIKE '%git%') OR (wp_rb_posts.post_content LIKE '%git%'))) AND (wp_rb_posts.post_password = '') AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC; 

Что касается меня, e, что одна проблема - это групповой символ%, используемый до и после литерала, т. е. операция Содержит строку. Например, гораздо более быстрый запрос - это LIKE 'git%' - StartsWith. Что касается других запросов, очень важно, чтобы вы сообщали, как ваши индексы определены в таблицах.

В качестве примера того, что я сделал бы в определенных ситуациях для решения проблемы% git%, является то, что я создам триггер (я работаю с MSSQL), который при операции вставки/обновления вычислял бы, если есть «git», строка, содержащаяся как в заголовке, так и в содержании записи, и если это так, пометьте поле бит как (true). Это замедлит операцию вставки/обновления в таблице (незначительно при вставке или обновлении только одной записи за раз), но это значительно увеличило бы производительность поискового запроса.

Answer 3

Во-первых, посмотрите на this нить на форуме поддержки (я вижу, что вы отправили туда помощь) - вы не единственный, у кого проблемы, и в этой теме есть несколько предложений.

Во-вторых, работа с удаленно размещенной базой данных для отладки проблем с производительностью - это ужасная игра, особенно если это ваш живой сервер. Для вашего собственного здравомыслия, я настоятельно рекомендую воссоздать систему на машине, на которой вы можете реально работать и экспериментировать.

По крайней мере, вам, вероятно, нужно запустить MySQL (в идеале в той же версии, что и ваш сервер), и восстановить базу данных из вашей живой среды.

Далее, выполняйте медленные запросы и выясните, что происходит - насколько я могу судить, ваши худшие нарушители не имеют соответствующих индексов.

SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 

выиграет от индекса соединения на to_ping и, возможно, post_status (мощность этого столбца может быть слишком низкой, чтобы помочь много).

SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID 
FROM wp_rb_posts 
WHERE 1 =1 
AND (
wp_rb_posts.post_author =56 
) 
AND wp_rb_posts.post_type = 'post' 
AND (
wp_rb_posts.post_status = 'publish' 
) 
ORDER BY wp_rb_posts.post_date DESC 
LIMIT 0 , 10 

выглядит как он имеет низкую мощность на большей части колонок тоже - но если у вас есть много строк, выбирая топ-10 на основе POST_DATE будет дорого; рассмотрим составной индекс для всех столбцов в предложении where плюс post_date.

SELECT wp_rb_posts.* 
FROM wp_rb_posts 
WHERE 1=1 
AND (
    (
     (wp_rb_posts.post_title LIKE '%git%') 
    OR 
     (wp_rb_posts.post_content LIKE '%git%') 
    ) 
    ) 
AND (wp_rb_posts.post_password = '') 
AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') 
AND (wp_rb_posts.post_status = 'publish') 
ORDER BY wp_rb_posts.post_date DESC; 

просто противно - текстовый поиск должен действительно использовать поиск freetext; это может быть очень медленным для большого набора данных. Если вы не можете изменить этот запрос, не знаете, что вы можете сделать, чтобы исправить его - вы можете добавить составной ключ в другие столбцы, но мне кажется, что этот запрос выполняет поиск текста во всех текущих сообщениях.

Создайте индексы на вашей локальной машине, измерьте, если они имеют какое-либо значение, и в идеале проверьте, что вы ничего не сломали (например, путем добавления уникального индекса случайно ...).