- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
HI! Столкнулся с трудностью. Создаю запрос к БД Mysql с высоким количеством строк (~1млн), в которых храниться только имя исполнителя, название и композиции, дата добавления и ссылка на загрузку. В общем БД занимает всего 130 МБ.
Создавая запросы на подсчет кол-ва записей, скрипт виснет до 8 секунд. Пример запроса:
mysql_query("select count(*) from materials where status='1' and section='$sec' and category='$cat' limit 1");БД - MyISAM, поле id,status,section,category - являются индексами. И не сказать, чтобы комп был совсем слабым - 4 ГБ ОЗУ, i5-3317U 1,7 ГГЦ.
Как уменьшить нагрузку? Хранить где то отдельно кол-во строк в таблице и периодически обновлять эту инфу?
А зачем этот запрос вообще?
Создайте отдельную таблицу и запищите туда подсчитанные данные. Нафиг mysql каждый раз их считать.
Хранить где то отдельно кол-во строк в таблице и периодически обновлять эту инфу?
Вполне логично; по сути - "кэширование" результата запроса.
По поводу обновления - почитайте про триггеры, возможно, будет полезно.
поле id,status,section,category - являются индексами.
И ещё про EXPLAIN и составные/композитные индексы (по нескольким полям)
Если там есть индексы, в идеале один составной на эти поля, то не может этот запрос выполнятся 8 сек. Limit оттуда вообще можно убрать. Или юзайте коунтер в отдельное поле
SHOW CREATE TABLE и EXPLAIN SELECT покажите
Я бы реализовал вот так: http://habrahabr.ru/post/47031/
Но тут хозяин-барин как говорится ))
Я бы реализовал вот так:
А чем вьюшка в данном случае поможет ТСу?
А чем вьюшка в данном случае поможет ТСу?
Основываясь на личном опыте обращение к вьюшке куда быстрее.
Покажите табличку (запрос SHOW CREATE TABLE `materials`)
Если поле статус - числовое, то не ставьте в запросе кавычки, будет сильно тормозить
select count(*) from materials where status=1 ...
LIMIT уберите, не надо..
Закешировать проще, имхо.
Я бы посчитал один раз и хранил это число где-то отдельно (в таблице с параметрами и настройками или даже можно в файле) и при добавлении новой записи просто наращивал бы, а при удалении соответственно убирал.
Пысы. Выше писали про триггеры. Насколько я знаю, можно с помощью них сделать такое вот автоматическое обновление при изменении количества записей.
mysql_query("select count(*) from materials where status='1' and section='$sec' and category='$cat' limit 1");
1) LIMIT 1 - не в тему, так как count(*)
2) Если section и category текстовые - сделайте их INT(номера секций и категорий, а текстовые значения вынести в другие таблицы).
Другой вариант:
2 триггера записывающие кол-во записей куда-то: 1-ый при INSERT, а 2-ой при DELETE. То есть: вставили строку - триггер сделал +1 в таблицу где хранится кол-во строк таблицы materials, удалили строку - триггер сделал -1.
У меня аналогичный(тока сложней) запрос к таблице на 4кк записей с 2-умя джоинами, подзапросом, условиями и группировкой выполняется около секунды на более слабом компе.
Может это не запрос на 8сек тормозит, а сам скрипт?