Точно! Не подумал как то что ему будет достаточно смотреть только с того id с которого я укажу.
Но по сути дела, если для первой страницы, то старт равен 0, разве в этом случае не получатся тоже самое по эффективности что ваш метод? ) (хотябы даже для первой страницы, а их я не более 10 разрешаю просматривать) А вообще щас сам проверю )
netwind, не желательно, а какой бы был тогда вариант?
тройной индекс возможно решение, но этими параметрами мало чего отсеивается, поэтому думаю что особо этот индекс нам не поможет )
ok - проверенная фотка.. т.е. почти все 1
ero - +18 таких очень мало, т.е. почти все 0
view - способ отображения, там тоже почти везде одно значение 0
А чем черевато having? я так понимаю это повторная проверка всех выбранных данных? только в этом проблема?
f.ok - почти для всех фоток
нет смысла ставить индексы на все данные таблицы..
собствено там такие поля как:
id cat user ok view ero (все числовые, индексы только на id/user)
чем плох having в данном случае?
с ним выполняется за 0.1, а если при поиске указать ero=1, думаю понятно что это, то он находит всего пару фоток и тогда время выполнения 0.5, но поиск с ero=1 мне не требуется, поэтому впринцепи и устраивает) (кстати число фоток 20к, оценок тоже 20к)
tinyint(1), да не в этом всё дело
я тут было подумал что раз я добавляю условие в where для фоток, то mysql выбирает сначало все фотки удовлетворяющие этому условию и все оценки 10, после чего сопостовляет по id..
но и это бы уместилось 0.1-0.2 сек, а откуда берётся аж 0.7..
впринцепи логика запроса такова
1. выбрать все оценки 10 из базы
2. сопоставить для них фотки по индексу
3. отсеить из всего этого по условиям для фоток
И ВОТ, меня осенило, как только написал эти пункты :)
а при использовании нескольких таблиц и подзапросов можно использовать доп. параметры отсеивания из полученого результата!! Осталось найти только как ))
where условия dontknow условия
или я ошибаюсь?
Нашёл - having
Спасибо за внимание )
Ваш вариант, за 0.714 сек, разницы нет.
Всё таки убивает тот факт что убрав числовые параметры отсеивания, что я указывал, уменьшает время выполнения в 10 раз. (это не кеширование в базе, делаю разные запросы)
прямо таки загадка..
(f.ok=1 and f.view=0 and f.ero=0) если использую в условии один из этих параметров(для фоток), то время 0.7 сек, а если их все убрать то получается время 0.062 сек
такое ощущение что если использовать один из параметров для фотки, mysql не проверяет фотку с соответствующим ID (on f.id=n.foto), а шурудит всю базу фоток для каждой оценки 😮
Пойду читать мануалы по джойнам )
Всё верно, больше от скрипта зависит, + можно ещё и кешировать много чего!
нехочу создавать новую тему, но есть у меня один интересный запрос на сайте, который смущёно требует 0.8сек, когда другие укладываются в 0.1 сек )
Вот сам запрос:
Смысл запроса такой что нужно выбрать все оценки 10 и соответствующие фотографии.
Индексы в поиске не участвуют, они стоят только на ID, участвуют только в сортировке.
Больше всего непонятно то что если убрать (f.ok=1 and f.view=0 and f.ero=0) из условия отсеивания, время запроса уменьшается в 10 раз.
Как же так? В чём тут загвозка? :(
как для одного сайта так помоему php-fpm не к чему, а вот если для нескольких пользователей, то нехватает такой фишки:
Динамическое количество процессов, в зависимости от нагрузки
Спасибо! Я тоже подобную инфу уже нашёл, сам Игорь Сысоев отписался ;)
Буду надеяться что так оно и есть.
AndreM, наверное хостер глушит демонов, многие так и делают
