И его последователь mpm peruser есть, наслышан, что там там куча багов на разных OS, да и работает ли с последним апачем? (баги вплоть до порождения огромного числа процессов и зависания OS)
особенно этот факт беспокоит, сколько и как шаманить прийдётся чтобы до ума довести 🙄
Вот видите, у вас 90мб, у меня 2 .. (сколько же коннектов допускаете, если каждый уже способен взять по 90мб) с сортировкой вся понятно ;)
using temporary - скорее всего тоже какой то лимит буфера нужно подкрутить..
Говорите ничего не меняется, появился using where для f, и кто знает какое время выполнения скрипта будет...
Нормальный вариант, только не 0711, а 0710
1 для группы, а в группе у нас апач, если он не от юзера запускается ☝
PS. жаль никто не поделится секретом как апач от юзера пускать с производительностью как у mod_php
Говорилось что лучше делить по 10тыс файлов на папку.
Мне интересно как система преобразует path в указатель к файлу на жёстком диске.
Скажем есть у нас /home/page/index.html
Я думал что делается запрос на папку /home/page/ по названию файла и получается указатель на этот фаил..
И ещё, например есть у нас папка в которой 1млн файлов, размер этой директории будет десятки мб, наврятли удастся её отрыть через что либо + к тому же если произойдёт ошибка в списке файлов директории, то несколько файлов при чтении директории могут пропасть , сами файлы конечно же не будут повреждены. (просто был уже случай что в фтп обычный файл не отображался а для чтения он был доступен)
нет.. я думаю тут дело именно в параметре sort buffer size=2M , но больше ставить вроде ни где не рекомендуют... просто ограничиваю при выборе базу оценок id<40000 и filesort пропадает... (мой Индекс 2,149.0 КБ )
какой у вас и какие параметры для sort buffer size / myisam sort buffer size
having: мой запрос видимо для mysql очень похож на группировку по n.foto=f.id (ведь несколько оценок для одной фотки)
если не использовать having то как не крути будет using temporary для n + where для f (соответственно долгое выполнение)
Почему у вас такого нет?
Очень просто, у вас условия только для одной таблицы, поставьте дополнительное условие для f как у меня (f.ok=1 and f.view=0 and f.ero=0), достаточно одного параметра на который нет индекса и всё переворачивается вверх дном ..
В принцепи я во всём разобрался, но ещё хотелось бы услышать что у вас получится после подстановки этого доп. условия для f.
netwind, сделал запрос идентичный вашему, всё равно для f => Using temporary; Using filesort
И хочу уточнить, у меня другой запрос, у вас не хватает where для таблицы f
Это у вас
where f.id=n.photo and n.rating=10.0 and n.approved=1
тут участвует только индекс от f.id и таблица n
Это мой
where f.id=n.foto and n.note=10 and f.ok=1 and f.view=0 and f.ero=0
тут участвуют обе таблицы, это и приводит у такому времени запроса 0.7 сек
Кстати что за феномен, убираю "order by n.id desc"
сразу пропадает Using temporary; Using filesort для f
У меня сервер... с оптимизацией самого mysql не заморачивался.. так как пока не прижало ))
Всё по умолчанию, ничего не менял
join buffer size 131,072
sort buffer size 2,097,144
из переменных mysql
Нет, не погрешность кеширования, не 1 раз проверял..
Хотите попробовать, вот таблички, но их нужно забить чем то:
Сколько они занимают у меня
tb_notes 85,712 записей MyISAM cp1251_general_ci 3.9 МБ
tb_fotos 12,654 записей MyISAM cp1251_general_ci 1.0 МБ
в тот раз что то я напутал на счёт того что 20к оценок, оказывается 85к )
RAS,
я описывал структуру чуть ранее, индексы только на (id,foto - таблица n) и на (id,user - таблица f), другие индексы нехочу прописывать так как это становится не целесообразно.
Это единственный такой замороченный запрос, другие в основном по индексам и с одной таблицей..
netwind,
Как это left убрать. Ну убрал я его и получилось что и с having и без него теперь более 0.7сек..
Изменилась эта строчка для таблицы n: [Extra] => Using temporary; Using filesort (пропал where)
Скорее всего в моём случае тройной индекс ускорит запрос, но этот индекс мне потом только боком выйдет.. так как таблицы очень динамические.. и растут довольно таки быстро, нужно экономить используя только основные индексы, а не ставить их на все данные таблицы)
Всё таки оптимизация запросов не лёгкая задача ;)
через пхп, но красивее )
меняю having на and
Варианты с лимитом без старта и условию по стартовому ID, для обоих запросов выгоды в скорости не приносит )
Всё перепробовал и по id вместо лимита.. единственное что улучшает это having, почти в 10 раз быстрее, впринцепи устраивает, не знаю как будет при увеличении базы.
Explain этого запроса
