Ключевые слова:mysql, optimization, (найти похожие документы)
Date: Tue, 25 Mar 2003 19:37:01 +0500
From: Dinky <[email protected]>
Newsgroups: ftn.su.dbms.sql
Subject: Потеря производительности при выборке в Mysql по ключам.
> А тормоза были из-за того, что при лимите N,M выбирается все равно N+M
> элементов(всех! :() (в данном случае > 200 000.. Я просто такого поведения не
> ожидал :(
поэкспериментировал, странно получается: имеем 5.5млн записей,
если запрашиваю все подряд:
SELECT * FROM mytable LIMIT 5000000,100
результат выдает через 2.5 сек, а если выбираю ключи:
SELECT keyfield1, keyfield2 FROM mytable LIMIT 5000000,100
то думает полминуты (проверял на разных диапазонах после 5млн)
он их что, заново пересортировыает? а я еще не просил order by...
и точно, стоит попросить отсортировать по ключам:
SELECT * FROM mytable ORDER BY keyfield1, keyfield2 LIMIT 5000000,100
так задумывается на полминуты, повторные запросы на близкие диапазоны
выполняются столько же....
вобщем, ну его нафиг все эти "расширения SQL", от лукавого они :)
From: Pavel Veller <[email protected]>
AO>> Делаю Експлайн на типичный запрос (которые базу и "нагибают" при
AO>> большом их количестве)
AO>> mysql> EXPLAIN select * from gbaccord ORDER BY id LIMIT 229232,200;
AO>> Если кто готов помочь разобратся в засаде - прошу отзовитесь! Мылом
AO>> (чтобы окружающих не
IZ> LIMIT твой и тормозит. 230 000 записей выбирает, а потом 200 тебе
IZ> выплевывает.
Более того. MySQL сначала все отсортирует, а потом отрезать будет.
Вот тут http://www.mysql.com/doc/en/ORDER_BY_optimisation.html подробно
описано как работает и как оптимизируется ORDER в MySQL.
Записей у тебя там много, так что за sort_buffer база точно вылазит и для
сортировки еще пишет много чего на диск. Попробуй во время такого вот
"просидающего" запроса посмотреть с консоли SHOW PROCESSLIST - увидишь все
стадии сортировки.
