Межах 0,5 робіць запыт запуску 350 разоў больш павольна,

Наступны запыт 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:

БЕЗ абмежаванні, 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
@ckruse: Калі ласка, глядзіце мой выбар вышэй.
дададзена аўтар ProgrammerGirl, крыніца
@GolezTrol: Калі ласка, глядзіце праўку вышэй для 2-х адрозніваецца EXPLAIN я атрымліваю для кожнага запыту (з/без LIMIT 0,5).
дададзена аўтар ProgrammerGirl, крыніца
@Adrian Корніш: SQL_NO_CACHE не мае ніякага значэння. ШОЎ індэкс АД Table1 пералічаны некалькі індэксаваная слупкоў паасобку, у тым ліку ўсіх слупкоў, якія змяшчаюцца ў запыце (col1, col2, і col3).
дададзена аўтар ProgrammerGirl, крыніца
Вы можаце дадаць «выбраць SQL_NO_CACHE», каб пераканацца, што вы атрымліваеце праўдзівыя вынікі сінхранізацыі і «SHOW INDEX FROM <�імя табліцы>» можа быць таксама добра. Не маглі б вы растлумачыць як запыты?
дададзена аўтар Adrian Cornish, крыніца
Хіба што растлумачыць простым для абодвух запытаў? Можа быць, ЛІМІТ сілы MySQL, выкарыстоўваючы іншы ключ.
дададзена аўтар GolezTrol, крыніца
Гэта можа быць карысным, як для аптымізацыі запытаў: databasejournal.com/features/mysql/article.php/1382791/…
дададзена аўтар Brad Christie, крыніца
Што кажа EXPLAIN?
дададзена аўтар ckruse, крыніца

2 адказы

Мяжа старт, рэнтабельнасць залежыць ад разліку рухавіка DB. Для пагинации не патрапілі ў БД кожныя 5 радкоў, лепш за ўсё было б, у прынесці 500 запісаў пярэдні канец, а затым абслугоўваць там з дапамогай JavaScript, на кожныя наступныя 500 запісаў патрапілі ў БД, якое будзе прымальна ..

0
дададзена
Але чаму б гэта зрабіць запыт у 350 разоў больш павольна, нават на пустым наборы вынікаў? Падобна на тое, што нешта яшчэ адбываецца ...
дададзена аўтар ProgrammerGirl, крыніца
Ён першым робіць выбарку запісаў, а затым выняць радкі, неабходныя, і ўставіць у temp_table, а затым здабывае патрэбныя радкі з temp_table ...
дададзена аўтар Sashi Kant, крыніца

Праблема заключаецца ў тым, што мяжа прымушае MySQL на заказ запыт першы, прымушаючы яго замовіць ўвесь набор, а затым працадзіце яго, а не з дапамогай індэксаў.

Ёсць дырэктывы, каб сказаць MySQL, які індэкс выкарыстоўваць, але можа быць лепш, каб стварыць камбінаваны індэкс па col1, col2 і col3. MySQL павінен выкарыстоўваць гэты індэкс для фільтрацыі і сартавання. Вы павінны эксперыментаваць, каб убачыць, ці з'яўляецца хутчэй запыт, калі col3 з'яўляецца першай або апошняй калонцы гэтага азначніка.

0
дададзена