Я использую Drupal 6 с MySQL версии 5.0.95 и в тупике, где один из моих запросов, который отображает контент на основе последней даты публикации, замедляется и из-за частоты использования полностью убивает производительность сайта. Этот вопрос выглядит следующим образом:
SELECT n.nid,
n.title,
ma.field_article_date_format_value,
ma.field_article_summary_value
FROM node n
INNER JOIN content_type_article ma ON n.nid=ma.nid
INNER JOIN term_node tn ON n.nid=tn.nid
WHERE tn.tid= 153
AND n.status=1
ORDER BY ma.field_article_date_format_value DESC
LIMIT 0, 11;
EXPLAIN запроса показывает результат ниже:
+----+-------------+-------+--------+--------------------------+---------+---------+----------------------+-------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+--------------------------+---------+---------+----------------------+-------+---------------------------------+
| 1 | SIMPLE | tn | ref | PRIMARY,nid | PRIMARY | 4 | const | 19006 | Using temporary; Using filesort |
| 1 | SIMPLE | ma | ref | nid,ix_article_date | nid | 4 | drupal_mm_stg.tn.nid | 1 | |
| 1 | SIMPLE | n | eq_ref | PRIMARY,node_status_type | PRIMARY | 4 | drupal_mm_stg.ma.nid | 1 | Using where |
+----+-------------+-------+--------+--------------------------+---------+---------+----------------------+-------+---------------------------------+
Этот запрос казался относительно простым и прямым и извлекал статьи, которые относятся к категории (термину) 153 и имеют статус 1 (опубликован). Но, по-видимому, используя временную таблицу и использование filesort означает, что запрос будет терпеть неудачу из того, что я узнал о нем.
Удаление field_article_date_format_value из предложения ORDER BY разрешает использование временного; Использование filesort уменьшает время выполнения запроса, но является обязательным и не может быть продано, к сожалению, одинаково справедливо и для производительности сайта.
Моя догадка заключается в том, что большая часть проблем связана с таблицей term_node, которая отображает статьи в категории и является таблицей отношений многих-многих, что означает, что статья X связана с 5 категориями C1.... C5 она будет иметь 5 записей в эта таблица, эта таблица из готового drupal.
Работа с тяжелым содержимым БД является для меня чем-то новым и проходящим через некоторые подобные запросы ( При заказе по дате desc, "Использование временных" замедляет запрос, Оптимизация производительности MySQL: порядок по дате времени) Я попытался создать составной индекс для content_type_article, чье поле datetime используется в предложении ORDER BY вместе с другим ключом (nid) в нем и попытался УКАЗАТЬ FORCE.
SELECT n.nid, n.title,
ma.field_article_date_format_value,
ma.field_article_summary_value
FROM node n
INNER JOIN content_type_article ma FORCE INDEX (ix_article_date) ON n.nid=ma.nid
INNER JOIN term_node tn ON n.nid=tn.nid
WHERE tn.tid= 153
AND n.status=1
ORDER BY ma.field_article_date_format_value DESC
LIMIT 0, 11;
Результат и следующий запрос EXPLAIN, похоже, мало помогли
+----+-------------+-------+--------+--------------------------+-----------------+---------+----------------------+-------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+--------------------------+-----------------+---------+----------------------+-------+---------------------------------+
| 1 | SIMPLE | tn | ref | PRIMARY,nid | PRIMARY | 4 | const | 18748 | Using temporary; Using filesort |
| 1 | SIMPLE | ma | ref | ix_article_date | ix_article_date | 4 | drupal_mm_stg.tn.nid | 1 | |
| 1 | SIMPLE | n | eq_ref | PRIMARY,node_status_type | PRIMARY | 4 | drupal_mm_stg.ma.nid | 1 | Using where |
+----+-------------+-------+--------+--------------------------+-----------------+---------+----------------------+-------+---------------------------------+
Все поля n.nid, ca.nid, ma.field_article_date_format_value индексируются. Запрос DB с лимитом 0,11 занимает приблизительно 7-10 секунд с предложением ORDER BY, но без него запрос едва занимает секунду. Ядром базы данных является MyISAM. Любая помощь по этому поводу будет с благодарностью.
Любой ответ, который может помочь мне в получении этого запроса, как обычный (с той же скоростью, что и запрос без сортировки по дате), будет отличным. Мои попытки создания составного запроса в виде комбинации nid и field_article_date_format_value и использования в запросе не помогли. Я открыт для предоставления дополнительной информации о проблеме и любых новых предложениях.
