- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
И прям спасает ситуацию?
Прям да.. =) А почему нет? MySQL поумнел, но ещё есть к чему стремиться..
Ан нет.. нифига не поможет..
В общем, если структуру не изменять (rating в первую таблицу не выносить) всё так же вижу один из вариантов:
а) Уходить от JOIN-а в сторону подзапроса (тут вряд ли прокатит)
б) JOIN-ить с выборкой с меньшим количеством записей (выбрать по рейтингу исходя из данных)..
в) условия из WHERE перенести в ON
Я больше к последнему склоняюсь.. =)
Я был бы предельно удивлён, если это сработало :)
все печально
все печально
Ну ни всё. Если слишком надо, всегда можно костыли сделать :)
Если слишком надо, всегда можно костыли сделать
Средствами PHP?
всегда можно костыли сделать
В смысле, изменить архитектуру приложения с учётом текущих потребностей?
Для 20 записей конструкция вполне рабочая.. для 200 - аналогично.. даже для 2000 на шареде может отработать без особых сложностей.
Можно даже без ухода в оптимизацию таблиц закэшировать результат выборки (насколько критично, что рейтинг будет отображаться с задержкой в 5-10 минут?.. или 15 секунд, если кэш пересчитывать при обновлении рейтинга)
Или продублировать поле (вообще отдельную memory-таблицу создать?) + добавить триггер на создание/обновление рейтинга.. если уж совсем "реалтайм" нужен..
Средствами PHP?
А почему бы и нет... скачать ID и рейтинг, отсортировать и потом просто выводить уже в нужном порядке записи по этим ID через WHERE IN(...)
Ничего смертельного в этом не вижу.
Выборка ID будет моментальной.
В любом случаи эту выборку можно кэшировать, хоть в файл на несколько часов или там уже как нужно.
Ничего смертельного в этом не вижу.
Я вот тоже не понимаю, когда люди упираются в чистые мускульные запросы, вместо того, чтобы разумно сочетать их с обработкой через пхп. На мой взгляд, во многих случаях последнее оптимальнее.
Я вот тоже не понимаю, когда люди упираются в чистые мускульные запросы, вместо того, чтобы разумно сочетать их с обработкой через пхп. На мой взгляд, во многих случаях последнее оптимальнее.
А это потому, что программисты некоторые делают программы для программистов, чтобы кодик был красивый и по феншую. А то, что программы пишутся для конечных пользователей, многие забывают.
---------- Добавлено 17.09.2019 в 14:23 ----------
p.s. ответственно могу заявить, что большинство платных тем для интернет-магазинов для WP или Opencart вообще не тестировались на более 1000 товаров.
Поэтому, то что у ТС такое на 500К это вообще героизм, и это надо решать и явно уже не только силами mysql т.к. даже 1-2 секунды выборки очень много, надо что-то делать и переделывать алгоритм работы.
продублировал поле rating в первую таблицу. добавил индекс. и все летает несмотря на 500к строк
спасибо за оказание помощи в тестировании ivan-lev