Заказать MySQL по оптимизации

Question

Ниже представлена ​​структура таблицы: -

Статья: ID, Название, Описание изделия, PublishedDateTime, ViewsCount, Опубликовано

Первичный ключ: ID

Запрос Used:

Select Title FROM Article ORDER By ViewsCount DESC, PublishedDateTime ASC 

Как вы можете видеть, я смешиваю ASC и DESC & в соответствии с заказом MySQL. Оптимизация индексов не будет использоваться.

Я думал использовать составной индекс, используя ViewsCount и PublishedDateTime. Вы рекомендуете использовать 2 разных ключа вместо использования составного индекса. Но затем я прочитал, что составной индекс лучше, чем использование 2 разных ключей (если оба поля будут использоваться).

Некоторые больше информации разделяют:

Таблица содержит более 550K + записи, а также у меня возникли большие проблемы в добавление и удаление индексов для целей тестирования. Что вы, ребята, рекомендуете? Должен ли я тестировать небольшой образец?

Ниже приведены еще некоторые идеи:

Индексы Б:
1) ViewsCount
2) PublishedDateTime.
3) ViewsCount & PublishedDateTime (назван ViewsDate_Index)

А) EXPLAIN запросов смешивания ASC и DESC:

EXPLAIN SELECT title FROM `article` ORDER BY ViewsCount DESC , PublishedDateTime ASC LIMIT 0 , 20  

====+===============+=========+======+===============+=====+=========+======+========+================+ 
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra 
1 | SIMPLE  | article | ALL | NULL   | NULL| NULL | NULL | 550116 | Using filesort 
====+===============+=========+======+===============+=====+=========+======+========+================+ 

B) EXPLAIN запроса, используя тот же порядок сортировки:

EXPLAIN SELECT title FROM `article` ORDER BY ViewsCount DESC , PublishedDateTime DESC LIMIT 0 , 20 

====+===============+=========+=======+===============+=================+=========+=============+========+================+ 
id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra 
1 | SIMPLE  | article | index | NULL   | ViewsDate_Index | 16  | NULL  | 550116 | 
====+===============+=========+=======+===============+=================+=========+=============+========+================+ 

Вы можете видеть, что если ViewsCount и PublishedDateTime находятся в одном порядке сортировки, то он использует индекс ViewsDate_Index. Единственное, что мне показалось странным, это то, что possible_keys NULL, и все же он выбирает индекс. Может кто-нибудь объяснить причину этого.

Также любые советы по добавлению индексов в эту таблицу, поскольку для добавления нового индекса требуется много времени. Любое обходное решение или помощь в этом отношении будут оценены.

Answer 1

Вперед, используйте индексы в своей базе данных.

Answer 2

Прежде всего, запустите весь запрос в прямом эфире и посмотрите, как он работает. Когда у вас есть некоторые тесты, подключите запрос к консоли MySQL и добавьте EXPLAIN к нему. MySQL не будет выполнять запрос, но он покажет, что он планирует выполнить запрос, в том числе там, где он считает важным оптимизировать, какие индексы он будет использовать, сколько строк он должен пересекать и насколько эффективно он будет проходить каждый набор ряды, между прочим. Лучший способ оценить проблему производительности - это бенчмаркинг. Используйте его часто.

Answer 3

На практике индексы не будут использоваться даже для ORDER By ViewsCount, PublishedDateTime здесь, так как вы ВЫБЕРИТЕ все столбцы и не применяете никаких условий. Это реальный запрос?Потому что любые условия испортит ваши оптимизации.

Если ваш стол настолько мал, что вы собираетесь его вытащить в целом, индексы замедлят ваш запрос. (Относится к исходному запросу: SELECT * FROM article ORDER BY ViewsCount DESC, PublishedDateTime;)

UPD

В случае, если у вас есть 500K + строки, я думаю, что вы собираетесь использовать LIMIT пункт. Я хотел бы сделать следующее:

1. добавить индекс (количества просмотров, PublishedDateTime)

2. переписать запрос следующим образом:

   SELECT Title 
   FROM (
       SELECT id 
       FROM article 
       ORDER BY ViewsCount DESC, PublishedDateTime 
       LIMIT 100, 100 
   ) ids 
   JOIN article 
   USING (id); 
   

Упорядочение выиграют от работающих на подмножество данных из индекса покрытия. Соединение будет просто получать титулы с помощью идентификаторов.

UPD2

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

SELECT Title 
FROM (
    SELECT ViewCount 
    FROM article 
    GROUP BY ViewCount DESC) as groups 
JOIN article USING (ViewCount) 
LIMIT 0, 100; 

Это, а также предполагает наличие (количества просмотров, PublishedDateTime) в таблице.