SQL_CALC_FOUND_ROWS "убивает" выборку

[donflash]

SQL_CALC_FOUND_ROWS "убивает" выборку

Просьба не кидать на поиск - уже посмотрел, но про тормоза чёт ничего особенного не увидел.

Имеем следующий запрос:

[sql]
SELECT SQL_CALC_FOUND_ROWS
Q.id
,Q.title
,Q.userid
,L.timestamp
,concat(U.first_name," ",U.last_name) as name
FROM
questions_info AS Q
LEFT JOIN lastactivity AS L ON L.userid = Q.userid
LEFT JOIN users AS U ON U.id = Q.userid
ORDER BY
Q.id DESC
LIMIT
0, 10
[/sql]

Вот на этом запросе всё затыкается, при кол-ве записей > 500K. Но, если сделать в два запроса (select count(*) from...), то всё просто летает. Вообще, я уже давно озадачился этой проблемой, но никак не могу понять причину, ведь фича очень полезная и удобная.

Индексы проставлены на всех таблицах, имеем mysql 5.0.45.

 

[Mr_Max]

чёт ничего особенного не увидел.

Хм... Как смотрел?

 

[donflash]

Темы, которые находятся поиском, в основном затрагивают проблемы использования того или иного способа для выдачи постраничной ерунды. Соглашусь, что на относительно небольшом объёме данных SQL_CALC_FOUND_ROWS работает быстро, но когда затрагиваются реально больше объёмы (например > 7 миллионов записей, то mysql падает в даун, но как тока меняешь на более привычный способ - сразу гут) умирает... Проблему тормозов я найти не смог, буду рад если меня кто-нить тыкнет

-~{}~ 28.01.08 23:24:

Вот провёл небольшой эксперимент...

Я упростил запрос до такого:
[sql]
SELECT SQL_CALC_FOUND_ROWS id, title, userid
FROM questions_info
ORDER BY id DESC
LIMIT 0, 10
[/sql]

Через профайл мне выводится следующее:

(initialization) 0.0000015
checking query cache for query 0.0000532
Opening tables 0.0000107
System lock 0.0000047
Table lock 0.0000457
init 0.0000197
optimizing 0.000004
statistics 0.000013
preparing 0.000011
executing 0.000003
Sorting result 22.433969
Sending data 0.0200925
end 0.0000107
query end 0.0000045
storing result in query cache 0.0000052
freeing items 0.0000102
closing tables 0.0000077
logging slow query 0.0000875

Отсюда становится понятно, что тормозит сортировка, но мля, причём тут сортировка и как SQL_CALC_FOUND_ROWS тут влияет?

Если убрать order by:

[sql]
SELECT SQL_CALC_FOUND_ROWS id, title, userid
FROM questions_info
LIMIT 0, 10
[/sql]

То получаем следующее:

(initialization) 0.0000015
checking query cache for query 0.000055
Opening tables 0.000013
System lock 0.0000062
Table lock 0.0000467
init 0.0000175
optimizing 0.000003
statistics 0.0000107
preparing 0.000009
executing 0.0000027
Sending data 0.0056292
end 0.0000085
query end 0.000004
storing result in query cache 0.0000035
freeing items 0.0000987
closing tables 0.000008
logging slow query 0.000002

 

[berkut]

donflash просвети тёмного, что за профайл такой? и получается[sql]
SELECT SQL_CALC_FOUND_ROWS id, title, userid
FROM questions_info
ORDER BY id DESC
LIMIT 0 , 10;

-- &

SELECT id, title, userid
FROM questions_info
ORDER BY id DESC
LIMIT 0 , 10;[/sql]
точно разнятся по времени?

 

[donflash]

donflash просвети тёмного, что за профайл такой?

http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html

точно разнятся по времени?

Точно, причём разница огромнейшая

 

[Gas]

To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?

Правда это не истинна в последней инстанции.

 

[donflash]

Gas
Спасибо за наводку, сам читаю этот блог, но как-то на эту статью не натыкался

 

[Wicked]

Gas, опередил .-)