- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
В общем проблема как всегда начинается когда на сайте появляется много данных, да ещё и запросы кривые.
Помогаю одному человеку, но, что то застрял на одном запросе.
(SELECT NAME FROM news_regions where id = N.id_region) AS region,
(SELECT NAME FROM news_category where id = N.id_category) AS category,
(SELECT NAME FROM news_sources where id = N.id_source) AS source
FROM news_news N
WHERE 1=1
AND N.id_category = 2
ORDER BY N.date DESC
LIMIT 12600,36;
при таком вот запросе выдаёт Отображает строки 0 - 29 (36 всего, запрос занял 3.0455 сек.) что не есть гуд.
записей в категории 2 где-то около полутора миллионов, вот и буксует.
помогите пожалуйста кто чем может )
Похоже, что тормозит offset в лимите.
Вот такой вариант пробовали?
Похоже, что тормозит offset в лимите.
Вот такой вариант пробовали?
думаю вы не совсем правы, потому как запрос с LIMIT 36 ; также срабатывает 3-4 секунды
Индексы? И да, при ордер бай и лимит для оптимизации следует выбирать сначала первичные ключи используя индекс.
а что LEFT JOIN уже не в моде? про индексы не забыли?
вообще обычно чтобы объединить несколько таблиц используют LEFT JOIN
например
и вместо * в вашем запросе лучше перечислить наименования полей которые выбираете, это тоже возможно поможет
rustrek, как раз недавно попался на этом.
Проблема в LIMIT http://habrahabr.ru/post/41968/
SELECT… FROM table LIMIT $start, $per_page
Многие думают, что подобный запрос вернет $per_page записей (обычно 10-20) и поэтому сработает быстро. Он и сработает быстро для нескольких первых страниц. Но если количество записей велико, и нужно выполнить запрос SELECT… FROM table LIMIT 1000000, 1000020, то для выполнения такого запроса MySQL сначала выберет 1000020 записей, отбросит первый миллион и вернет 20. Это может быть совсем не быстро. Тривиальных путей решения проблемы нет. Многие просто ограничивают количество доступных страниц разумным числом. Также можно ускорить подобные запросы использованием покрывающих индексов или сторонних решений (например sphinx).
то то застрял на одном запросе.
Там 4 запроса, а не 1. Культурные люди так не делают. Как делают культурные люди - см.выше.
думаю вы не совсем правы, потому как запрос с LIMIT 36 ; также срабатывает 3-4 секунды
Т.е. простой запрос тормозит?
Сколько по времени выполняется запрос ниже?
SELECT * FROM news_news
WHERE id_category = 2
ORDER BY date DESC
LIMIT 36;
Т.е. простой запрос тормозит?
Сколько по времени выполняется запрос ниже?
этот вот
Отображает строки 0 - 29 (36 всего, запрос занял 3.0439 сек.)
---------- Добавлено 03.08.2015 в 14:51 ----------
вообще обычно чтобы объединить несколько таблиц используют LEFT JOIN
например ....
и вместо * в вашем запросе лучше перечислить наименования полей которые выбираете, это тоже возможно поможет
спасибо, запрос выдаёт ошибку #1054 - Unknown column 'N.NAME' in 'field list'
Отображает строки 0 - 29 (36 всего, запрос занял 3.0439 сек.)
Индексы?
+ SHOW CREATE TABLE и EXPLAIN SELECT приведите.