да, число принимающих процессов не бесконечно. при большом числе соединений от спамеров он может прекратить принимать входящие от обычных пользователей.
уменьшайте лимиты ожидания, настраивайте greylisting, купите Communigate Pro :)
антиспам зачастую может вообще сервер "завесить"
у меня есть подобный сайт там 110 тыс комментов и 8 тыс фото c похожей структурой БД.
ну нету там никаких сортировок и временных таблиц.
Вот запрос примерно по-вашей методике :
explain select f.*,username as noteuser from `photo_comments` n left join `photo_photos` f on (f.id=n.photo) where n.rating=10.0 having f.approved=1 order by n.id desc limit 500,2;
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-----------------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-----------------------------+| 1 | SIMPLE | n | ALL | NULL | NULL | NULL | NULL | 110103 | Using where; Using filesort || 1 | SIMPLE | f | eq_ref | PRIMARY | PRIMARY | 4 | xxxxxxx.n.photo | 1 | |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-----------------------------+
а это до использования травы (having и left join) :
explain select f.*,username as noteuser from `photo_comments` n ,`photo_photos` f where f.id=n.photo and n.rating=10.0 and n.approved=1 order by n.id desc limit 500,2;
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-------------+| 1 | SIMPLE | n | index | photo | PRIMARY | 4 | NULL | 110103 | Using where || 1 | SIMPLE | f | eq_ref | PRIMARY | PRIMARY | 4 | xxxxxxx.n.photo | 1 | |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+-------------+
Сортировки нет!
Только вот точно оценить время я не могу. Получается примерно одинаково в обоих случаях от 0 до 1 сек.
Дисковый кеш и другие процессы сказываются. Да и 8мб данных это смех. Однако, я считаю, стоит верить explain-у.
там не VPS ?
Может вам mysql "разогнать" ? увеличить sort_buffer_size, join_buffer_size и тд?
Dimanych, честно говоря, не понимаю почему с HAVING это быстрее работает. Having без группировки в других субд вообще получается синтаксически неправильным.
может просто погрешности кеширования? вы в курсе про SQL_NO_CACHE ?
А если показать show create table будет просто удобнее воссоздать у себя и потестировать.
А еще ваш top показывает что mysql съел всего 32 мб памяти и памяти у вас очень много.
возможно все не так уж страшно. попробуйте просто увеличить key_buffer хотя бы до 200мб.
Dimanych, а если еще и left убирать? думаю, просто много данных в f и остается только тройной индекс создать
это сейчас или раньше?
приведите полные тексты запросов и explain к каждому. и лучше без этой гадости phpшной - глаза сломать можно.
По-моему, по умолчанию "FXP" нигде не работает.
По сути FXP не существует как протокол, но существуют сервера с отключаемой проверкой на адрес соединения с данными.
заходите на один из хостингов через ssh и изучайте консольный ftp-клиент.
там может случайно оказаться ncftp или lftp.
RAS, если было удобно - не было бы этой темы. неудобно.
например, вот эта древняя капча достаточно сложна и оформлена функциями : http://www.puremango.co.uk/cm_php_captcha_script_113.php
интегрируется куда угодно
Я подозреваю,что у вас все тормоза возникают на сортировке, которая выполняется во временных файлах. Возможно, если в explain пропадет "Using filesort" - будет эффект. Кстати, вас тут уже не просто так просили показать explain запроса.
А потом, если результат неудовлетворительный, можно попробовать индекс по трем полям. Увлечение индексами не должно быть чрезмерным - их же нужно при изменениях в таблицах обновлять тоже.
