помогите сделать грамотный запрос

[Fortop]

dimagolov
тебе же сказали, что SQL_CALC_FOUND_ROWS не оптимизирован по ключам в отличии от COUNT(*), то есть сильно медленней

Жесть.
Я профайлинг для галочки постил?

Где сильно медленней?!

 

[Вурдалак]

musicant
Автор кода просто тупо заменил COUNT(*) на SQL_CALC_FOUND_ROWS лол. То есть как было два запроса, так и осталось. И где смысл?

 

[musicant]

Автор оригинала: Вурдалак
musicant
Автор кода просто тупо заменил COUNT(*) на SQL_CALC_FOUND_ROWS лол. То есть как было два запроса, так и осталось. И где смысл?

Тогда можно еще вопрос в завершение темы?

У меня сейчас получается вот такой громоздкий запрос:

SELECT SQL_CALC_FOUND_ROWS  Allocation.Hotel_id, Allocation.nights, Allocation.beds, Allocation.extbeds, 
Allocation.adults, Allocation.children, Allocation.roomCategory_id, Price.start_date, Price.Tour_id, Price.value, 
Board.name AS board_name, RoomType.name AS RoomTypeName, Hotel.name AS hotname, Hotel.stars, 
City.name AS city_name, Tour.Currency_id, Currency.name AS curr_name, RoomCategory.name AS roomcat,
 RoomCategory.id AS room_id, Resort.name AS resort_name, Country.name AS country_name FROM  Allocation
INNER JOIN Price  ON Allocation.Price_id=Price.id 
INNER JOIN Board ON Board.id=Allocation.Board_id 
INNER JOIN RoomType ON RoomType.id=Allocation.RoomType_id
INNER JOIN Hotel ON Allocation.Hotel_id=Hotel.id
INNER JOIN City ON Hotel.City_id=City.id
INNER JOIN Tour ON Tour.id=Price.Tour_id
INNER JOIN Currency ON Currency.id=Tour.Currency_id
INNER JOIN RoomCategory ON RoomCategory.id=Allocation.roomCategory_id
INNER JOIN Resort ON Resort.id=City.Resort_id
INNER JOIN Country ON Country.id=City.Country_id
 $where  ORDER BY Price.id DESC  LIMIT  $start, $onPage

В результате может быть выведено более 60тыс строк.
Есть ли смысл переделывать его на COUNT(*)?
Сейчас я пользуюсь приведенным на прошлой странице кодом для постраничного вывода.

 

[Fortop]

В результате может быть выведено более 60тыс строк.
Есть ли смысл переделывать его на COUNT(*)?

Во-первых, 60к строк ты же не будешь отдавать пользователю?
Во-вторых, возьми и замерь скорость выборки с SQL_CALC_FOUND_ROWS и с COUNT(*) конкретно в твоем случае

в клиенте mysql

set profiling=1;
//тут запросы
show profiles;

 

[musicant]

Автор оригинала: Fortop
Во-первых, 60к строк ты же не будешь отдавать пользователю?

ЛЕГКО!
Если пользователь выберет только одно условие поиска (в данном случае Страна) - он получит по этой стране все варианты курортов со всеми отелями всех городов, все категории номеров и т.д и т.д.

 

[ps2007]

Ты же не будешь выводить все 60К строк на одной странице. Будет разбиение по страницам. Т.е. в запросе будет стоять LIMIT

 

[musicant]

ps2007
ну это естественно. LIMIT же указан в моем запросе выше.

 

[dimagolov]

Fortop, я ориентировался на ссыку, которую давал zerkms (http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/)
потому что в условиях кеширования нужно смотреть в первую очередь explain, а он сильно разный выходил.

 

[musicant]

Подскажите, как правильно использовать WHERE BETWEEN дата AND дата2
если пишу BETWEEN 2010-02-26 AND 2010-03-10 - возвращает 0 строк.

В PhpMyAdmin можно написать BETWEEN STR_TO_DATE('2010-02-26 00:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2010-03-26 00:00:00', '%Y-%m-%d %H:%i:%s')
А как быть в PHP скрипте?

P.S. в базе даты записаны в формате date

 

[zerkms]

BETWEEN 2010-02-26 AND 2010-03-10

кавычки забыл?

 

[Вурдалак]

WHERE ??? BETWEEN ??? AND ???

 

[zerkms]

а, ну и поле ага )

 

[musicant]

Вурдалак
zerkms
Не, ну поле-то я конечно указал )))
А вот кавычки действительно забыл.......