LIMIT 0,5 робить запит 350 разів SLOWER

Наступний запит MySQL завершується в 0,02 секунди :

 SELECT
    *
 FROM
    `Table1`
 WHERE
    `col1`     = '43532' AND
    `col2`     = 'N'
 ORDER BY col3 DESC 

Однак, якщо я додам LIMIT 0, 5 в кінці його, він завершиться через 7 секунд :

 SELECT
    *
 FROM
    `Table1`
 WHERE
    `col1`     = '43532' AND
    `col2`     = 'N'
 ORDER BY col3 DESC 
 LIMIT 0, 5

Це відбувається навіть тоді, коли запит повертає порожній набір результатів.

Чому додавання LIMIT 0, 5 призводить до того, що цей простий запит буде 350 разів повільний? Мені потрібно обмежувати результати за міркуваннями, тому як я можу це виправити?

EDIT:

БЕЗ LIMIT, EXPLAIN говорить:

id  select_type table   type    possible_keys   key     key_len   ref     rows  Extra
1   SIMPLE      Table1  ref     col1,col2       col1    5         const   2441  Using where; Using filesort

З LIMIT, EXPLAIN каже:

id  select_type table   type    possible_keys   key   key_len   ref   rows  Extra
1   SIMPLE      Table1  index   col1,col2       col3  5         NULL  1050  Using where
0
@ crruse: будь ласка, перегляньте мій редагування вище.
додано Автор ProgrammerGirl, джерело
@GolezTrol: Ознайомтеся з новим EDIT вище для двох різних EXPLAIN, які я отримую для кожного запиту (з/без LIMIT 0,5).
додано Автор ProgrammerGirl, джерело
@ Адріан Корніш: SQL_NO_CACHE не змінився. ІНДЕКС ШОУ З таблиці 1 перелічено кілька індексованих стовпців окремо, включаючи всі стовпці, що містяться в запиті (col1, col2 та col3).
додано Автор ProgrammerGirl, джерело
Чи можете ви додати "вибрати SQL_NO_CACHE", щоб переконатися, що ви отримуєте вірні результати часу, і "INDOW INDOW FROM <tablename>" може також бути добре. Не могли б ви також розкрити обидва запити?
додано Автор Adrian Cornish, джерело
Чи є це пояснення простими для обох запитів? Може бути, LIMIT сили MySQL використовують інший ключ.
додано Автор GolezTrol, джерело
Це може бути корисним, як оптимізувати запити: databasejournal.com/features/mysql/article.php/1382791/…
додано Автор Brad Christie, джерело
Що розповідає EXPLAIN?
додано Автор ckruse, джерело

2 Відповіді

Граничний початок, маржа залежить від розрахунку двигуна БД. Для сторінок не потрапляє до БД за кожні 5 рядків, найкраще буде, ви принесете 500 записів інтерфейс, а потім обслуговувати там через JavaScript, для кожного наступного 500 записів потрапив в БД, який буде прийнятним ..

0
додано
Але чому б вона зробила запит у 350 разів повільніше навіть на порожньому наборі результатів? Здається, що щось інше відбувається ...
додано Автор ProgrammerGirl, джерело
Вона спочатку вибирає записи, а потім витягує необхідні рядки та вставляє у temp_table, а потім витягує потрібні рядки з temp_table ...
додано Автор Sashi Kant, джерело

Проблема в тому, що межа спричиняє MySQL замовлення запиту спочатку, змушуючи його замовити весь набір, а потім фільтрувати його, не використовуючи індекси.

Є директиви, щоб повідомити MySQL, який індекс використовувати, але краще створити комбінований індекс на col1, col2 та col3. MySQL повинен використовувати цей індекс для фільтрації та сортування. Ви повинні експериментувати, щоб перевірити, чи відповідає запит швидше, якщо col3 - це перший або останній стовпець цього індексу.

0
додано
IT KPI - Databases
IT KPI - Databases
162 учасників