Стали подвисать запросы к БД

Axel

Client
Регистрация
20.03.2017
Сообщения
123
Благодарностей
6
Баллы
18
Использую локально OpenServer. Все работало хорошо, но со временем при выполнении проекта стали все боьлше подвисать запросы SELECT к БД MySQL. Подскажите, что это может быть?

Подвисает примерно 5-10 % запусков проекта, из 100 запусков 90-95 выполняются, остальные ошибки. Скорее всего дело в OpenServer, но как разобраться
 

zortexx

Client
Регистрация
19.09.2011
Сообщения
2 520
Благодарностей
1 225
Баллы
113

Lord_Alfred

Client
Регистрация
09.10.2015
Сообщения
3 916
Благодарностей
3 865
Баллы
113
Скорее всего дело в OpenServer, но как разобраться
Скорее всего дело в самой базе, т.е. в отсутствии индексов / плохой архитектуре / неоптимальных запросах.

Начинать с тюнинга настроек, не выяснив в чем проблема - плохой совет.

Первоначально нужно посмотреть медленные запросы (slow query log, см. гугл как включить их логирование), а потом пройтись по всем и разобраться с "EXPLAIN [запрос]".
И уже только после этого, поняв и расставив правильные индексы и исправив запросы - уже только тогда смотреть что там тюнер предложит поменять (и то нельзя менять вслепую, не погуглив что за что отвечает, а то станет ещё хуже :bm:).

PS: инфа по теме:
https://ruhighload.com/Как+включить+slow+log+в+mysql?
https://ruhighload.com/Индексы+в+mysql - обязательно к прочтению всем!
https://ruhighload.com/explain+в+mysql
https://ruhighload.com/Как+правильно+поставить+индексы+в+mysql?
https://ruhighload.com/index.php/2009/07/28/maatkit-расширенные-возможности-mysql/
https://ruhighload.com/Выбор+типов+данных+в+mysql - снова обязательно к прочтению!
https://ruhighload.com/Определение+лишних+индексов+в+mysql

PPS: прям скопипащу то, что пишут в одной из статей выше:
Когда создавать индексы?
  • Индексы следует создавать по мере обнаружения медленных запросов. В этом поможет slow log в MySQL. Запросы, которые выполняются более 1 секунды являются первыми кандидатами на оптимизацию.
  • Начинайте создание индексов с самых частых запросов. Запрос, выполняющийся секунду, но 1000 раз в день наносит больше ущерба, чем 10-секундный запрос, который выполняется несколько раз в день.
  • Не создавайте индексы на таблицах, число записей в которых меньше нескольких тысяч. Для таких размеров выигрыш от использования индекса будет почти незаметен.
  • Не создавайте индексы заранее, например, в среде разработки. Индексы должны устанавливаться исключительно под форму и тип нагрузки работающей системы.
  • Удаляйте неиспользуемые индексы.
Самое важное

Выделяйте достаточно времени на анализ и организацию индексов в MySQL (и других базах данных). На это может уйти намного больше времени, чем на проектирование структуры базы данных. Удобно будет организовать тестовую среду с копией реальных данных и проверять там разные структуры индексов.

Не создавайте индексы на каждую колонку, которая есть в запросе, MySQL так не работает. Используйте уникальные индексы, где необходимо. Всегда устанавливайте первичные ключи.

Не ссыте.
 
Последнее редактирование:

zortexx

Client
Регистрация
19.09.2011
Сообщения
2 520
Благодарностей
1 225
Баллы
113
Скорее всего дело в самой базе, т.е. в отсутствии индексов / плохой архитектуре / неоптимальных запросах.


Начинать с тюнинга настроек, не выяснив в чем проблема - плохой совет.

Первоначально нужно посмотреть медленные запросы (slow query log, см. гугл как включить их логирование), а потом пройтись по всем и разобраться с "EXPLAIN [запрос]".
И уже только после этого, поняв и расставив правильные индексы и исправив запросы - уже только тогда смотреть что там тюнер предложит поменять (и то нельзя менять вслепую, не погуглив что за что отвечает, а то станет ещё хуже :bm:).

PS: инфа по теме:
https://ruhighload.com/Как+включить+slow+log+в+mysql?
https://ruhighload.com/Индексы+в+mysql - обязательно к прочтению всем!
https://ruhighload.com/explain+в+mysql
https://ruhighload.com/Как+правильно+поставить+индексы+в+mysql?
https://ruhighload.com/index.php/2009/07/28/maatkit-расширенные-возможности-mysql/
https://ruhighload.com/Выбор+типов+данных+в+mysql - снова обязательно к прочтению!
https://ruhighload.com/Определение+лишних+индексов+в+mysql

PPS: прям скопипащу то, что пишут в одной из статей выше:
Для новичка, совет, как раз таки хороший, поскольку все эти тюнеры делают всю диагностику и выдают рекомендации основываясь на полученных диагностических данных.

А вот следуя вашей доктрине, ТСу для начала придется вкурить пару мегабайт документации и разобраться с принципами работы СУБД. Это не плохо, но по эффективности сильно уступает предложенному мной варианту.
 

Lord_Alfred

Client
Регистрация
09.10.2015
Сообщения
3 916
Благодарностей
3 865
Баллы
113
А вот следуя вашей доктрине, ТСу для начала придется вкурить пару мегабайт документации и разобраться с принципами работы СУБД. Это не плохо, но по эффективности сильно уступает предложенному мной варианту.
И пусть вкурит, это гораздо полезнее чем поменять пару настроек в конфиге, не понимая за что они отвечают, а через неделю (когда данных станет х 10 или х 100 раз больше) - снова словить ту же деградацию, но уже на оттюнингованных настройках :-)

PS: решать всё равно ТС'у как быть, но лучше знать о таком заранее.
 

zortexx

Client
Регистрация
19.09.2011
Сообщения
2 520
Благодарностей
1 225
Баллы
113
И пусть вкурит, это гораздо полезнее чем поменять пару настроек в конфиге, не понимая за что они отвечают, а через неделю (когда данных станет х 10 или х 100 раз больше) - снова словить ту же деградацию, но уже на оттюнингованных настройках :-)
Ага, пусть вкуривает. А работа пока пусть стоит. Отличный совет :-)

PS: решать всё равно ТС'у как быть, но лучше знать о таком заранее.
Тут согласен. Решать ему. Но выбор и его последствия должны быть осознанными.
 

Кто просматривает тему: (Всего: 2, Пользователи: 0, Гости: 2)