- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет
есть две таблици p и e
в таблице е есть поле rating на котором index. записей около 500 тыс
запрос вида
работает быстро. но если мы добавляем ORDER BY rating то беда. по 15 сек запрос. при чем прикол в том что если ставить
ORDER BY date или ORDER BY fixed. где поля date и fixed от таблици р то тоже быстро. но если брать любое поле с таблици е и сделать по нему ORDER BY то 15-17сек
Добавьте индекс в таблицу e
не помогло.
не помогло.
Что Explain говорит?
я в нем не разбираюсь. но вот ето http://skrinshoter.ru/s/160919/6i1R64AI
Есть предположения.. пробовать надо.
Если нет опасений - можете скинуть доступ в личку. Кроме добавления индексов и запросов на выборку делать ничего не буду..
Я бы ещё профилирование сделал запроса, чтобы точно посмотреть, из-за чего там идёт такое.
Ещё вариант, вместо JOIN заюзать подзапрос SELECT, и потом просто связать их.
но если брать любое поле с таблици е и сделать по нему ORDER BY то 15-17сек
Да, фактически так и получается https://forums.mysql.com/read.php?115,519488,520284#msg-520284
Единственный способ - иметь поля, по которым проводится отбор и сортировка в одной таблице.
One possibility -- Maintain (redundantly) another table with _only_ the valid rows.
Вариант с подзапросом мог бы прокатить.. если подзапросом значительно удастся количество записей уменьшить...
Т.е. по фэн-шую продублировать rating в первую таблицу.. и обновлять его.. или триггером, или по cron-у.
---------- Добавлено 16.09.2019 в 20:50 ----------
Я бы ещё профилирование сделал запроса, чтобы точно посмотреть, из-за чего там идёт такое.
Из-за temporary + filesort и идёт.
У меня дикая идея, если по рейтингу сортировать то менять местами JOIN :)
У меня дикая идея, если по рейтингу сортировать то менять местами JOIN
https://www.percona.com/blog/2006/09/01/mysql-order-by-limit-performance-optimization/
Но, судя по Explain-у, MySQL (поумнел)) вполне нормально пользует индексы из "вторых" таблиц (если не используется сортировка по полям первой, конечно))
Конкретно в этом случае есть более интересный вариант.. :D
LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE p.category IN ('1') AND date < '2019-09-14 16:22:23' AND approve=1 LIMIT 0,100
И прям спасает ситуацию?