Пара вопросов спецам по мускулу

Ваш вариант, за 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), а шурудит всю базу фоток для каждой оценки 😮

Пойду читать мануалы по джойнам )

видимо при использовании условий типа " and " в не подходящем месте индексы перестают работать. на офсайте про это где то было, я не прграммист , поэтому точно не скажу, где -то в примерах о правильных и не правильных индексах

А какой формат числовых полей?

tinyint(1), да не в этом всё дело

я тут было подумал что раз я добавляю условие в where для фоток, то mysql выбирает сначало все фотки удовлетворяющие этому условию и все оценки 10, после чего сопостовляет по id..

но и это бы уместилось 0.1-0.2 сек, а откуда берётся аж 0.7..

впринцепи логика запроса такова

1. выбрать все оценки 10 из базы

2. сопоставить для них фотки по индексу

3. отсеить из всего этого по условиям для фоток

И ВОТ, меня осенило, как только написал эти пункты :)

а при использовании нескольких таблиц и подзапросов можно использовать доп. параметры отсеивания из полученого результата!! Осталось найти только как ))

where условия dontknow условия

или я ошибаюсь?

Нашёл - having

Спасибо за внимание )

Дисков то хватит, на данный момент объем базы полтерабайта. Сервис начал неподетски тормозить.

Имхо, это не лучший вариант. Точнее это не вариант, ибо решает проблему удаления гландов через непредназначенные для этого места :)

Если какое-то какое-то значение будет иметь больше чем 30% (? точно не помню ) процентов от общего количества, то он индекс по этому полую не будет учитываться в запросе.

Как решение можно предложить сделать тройной индекс по f.ok, f.view, f.ero.

Но предварительно нужно знать структуру таблицы, которая обозначается как f и EXPLAIN запроса.

Если вы озвучите данную информацию, то возможно можно будет что-то посоветовать что-то более конкретное :)

f.ok - почти для всех фоток

нет смысла ставить индексы на все данные таблицы..

собствено там такие поля как:

id cat user ok view ero (все числовые, индексы только на id/user)

чем плох having в данном случае?

с ним выполняется за 0.1, а если при поиске указать ero=1, думаю понятно что это, то он находит всего пару фоток и тогда время выполнения 0.5, но поиск с ero=1 мне не требуется, поэтому впринцепи и устраивает) (кстати число фоток 20к, оценок тоже 20к)

Я бы не рискнул размещать столь крупные проекты на MySQL особенно если MyISAM, Oracle и MSSQL конечно круто, но дорого (Oracle Express не в счет), потому единственный масштабируемый и бесплатный выбор PostgreSQL.

Для начала стоит разобраться в чем узкое место. Хотя бы mysqltuner запустить и посмотреть slow log.

А там уже и думать как решать проблему - то ли памяти добавлять, то ли оптимизировать индексы - добавить нужные или уменьшить их размер, удалив редкоиспользуемые, но большие. Или думать как структуру базы и запросов менять.

Я очень сомневаюсь, что механическое перенесение базы на другое ПО даст адекватные резуьтаты.

Естественно это все делается, и запросы уже приведены к минимуму и кешируется все что можно. На счет постгресс, плавали. Вероятно он и будет держать большие нагрузки, но на таком объеме показал результат хуже чем мускул.

Склоняюсь все же к мысле попробовать 11-й Oracle