Катнул к морю, есть прикольные тропы, но такого очень мало. https://imgur.com/a/e7S0YSI---------- Добавлено 21.04.2020 в 21:41 ----------koketkade, на чём тулишь так? электричка? какая скорость на последнем видосе?
Понравился. Всего 4 серии, каждая чуть больше часа. Сериал основан на реальных событиях, про то как 5 негров изнасиловали девушку (да, я умею писать анонсы к сериалам). На самом деле, сюжет лучше не читать, т.к. история реальная и там спойлеры. Сыграно отлично, 4 серию немного затянули. Оценочка 8/10.
Когда они нас увидят.
Dram, хинты для индексов используйте после FROM.
Вместо INNER JOIN можно использовать STRAIGHT_JOIN.
Попробуйте INNER JOIN поднять выше, я так понимаю логики запроса он не изменит.
Составной индекс на id, mk_code есть?
Где EXPLAIN и структура таблиц?
iSmel, есть регекспы, но парсить HTML регекспами не совсем умная затея. Какая версия MySQL?
AlenDelan, это все от вас зависит. Как сделаете, так и будет. Я делал такой прогресс-бар через вебсокеты, тут есть пример его работы
А что с файлами делается? И что за бекенд у вас? Если nginx - то он сначала буферизирует запрос, затем передает его на php. Если что-то другое, то может быть потоковая обработка: пока файлы шлются (медленно), они обрабатываются (тоже медленно), и в итоге последняя долетевшая пачка байтов быстро обрабатывается, и отдается ответ.
Ну тут два пути, либо симулировать загрузку, двигая прогресс бар. Например, тот же YouTube так делает, ползунок ползет по таймеру, а не по результатам загрузки или ответу от сервера. Если задача "долгоиграющая", например выгрузка какая-то, можно сделать отдельный URL и UUID у задачи, по урлу можно получить current, total, percent, а на фронте рисовать прогресс на основании того, сколько бекенд уже обработал. То что у вас сервер 20 секунд что-то делает, фронтенд никак не узнает о том, сколько ещё осталось, если вы не научите фронтенд узнавать это отдельно, делая запросы.---------- Добавлено 30.03.2020 в 19:00 ----------AlenDelan, если в хроме троттлинг скорости включить, тоже быстро пишет что загрузилось?
Партиционирование по хешу тоже делит данные эффективно. Учитывая, что там можно использовать даже PARTITION BY HASH (id div 1000), таким образом ряд из 1000 непрерывных id попадет в одну и ту же партицию. И можно даже range запросы делать по ним. Оптимизатор знает, в какую партицию ему сходить на основании запроса. Ему нужно ходить по дереву небольшой партиции, вместо большого дерева одной жирной таблицы. Вставка, кстати, тоже более эффективна.
А почему количество подмножеств должно быть равно степени двойки? :)
С чего вы это взяли?
