MySQL Creating Sort Index создается очень долго

MySQL Creating Sort Index создается очень долго

Давайте рассмотрим случай, когда сайт в какой то момент времени (обычно это происходит быстро) перестает работать так же быстро, как раньше (например 1 час назад), при этом время загрузки может быть больше, чем > 1 минута. Первым делом пойдем смотреть процессы htop/top или аналог, что бы сделать первичный осмотр и выявить процесс который выполняется больше или больше всех. Но большому счету на сервере в большинстве случаев всего 2-3 процесса, которые находятся в “топе” по запросу ресурсов: php, nginx/apache, mysql. Посмотрели на процессы, mysql похоже больше всех сейчас “ест” ресурсы. Я использую heidisql для работы с БД, программа бесплатная, есть все для работы/жизни, удобный и понятный UI. Заходим в процессы или можем набрать команду в консоли mysql сервера

SELECT `ID`, `USER`, `HOST`, `DB`, `COMMAND`, `TIME`, `STATE`, LEFT(`INFO`, 51200) AS `Info` FROM `information_schema`.`PROCESSLIST`;

У нас будет список процессов, среди которых будет Creating Sort Index, что это, почему он выполняется так много времени, от 1-1,5 минуты и как с ним бороться или не стоит?

Немного отойдем от темы.

Есть несколько таблиц, которые наиболее часто используются в рабочей логике Magento и которые имеют порой достаточно внушительные размеры: 1, 5, 10 Гб и более. Особенно если товаров более 50К то размер таблиц растёт.

По опыту могу сказать что в магазинах с 18-20К товаров и 830+ атрибутов размер БД составляет 4-5Гб это со статистикой посещений и заказами, которые тоже играют большую роль, ведь, чем больше посещений, то скорее всего и больше заказов. Есть так же магазины у которых 6 витрин для разных континентов, 92К товаров 305К+ заказов, 78+ атрибутов, размер БД составляет 12-15Гб. Есть сайты у которых 40-45Гб база и я думаю это не предел для интернет магазина, который ведет достаточно большой объем продаж, товаров, операций.

В Magento v. 1.9.0.1 есть класс Mage_Catalog_Helper_Category_Url_Rewrite  Category url rewrite helper который содержит функции добавления URL для товаров и категорий и есть в этом одна особенность, которая на первый взгляд является безобидной, включение таблиц происходит, через JOIN LEFT

JOIN LEFT возвращает все записи из таблицы table1 (левая часть запроса) и проверяет на соответствие данные из таблицы table2 (правая часть запроса), если соответствие не найдено, то будет возвращено NULL. Если у нас таблица имеет “приличный” размер 50-60К записей, то над каждой записью будет произведена операция сравнения. В этом случае требуется создать INDEX для полей которые сравниваются и извлекаются, что бы операция сравнения проходила быстрее. Но в этом тоже есть свое “но”, которое мы рассматривать сейчас не будем. В нашем случае использование JOIN LEFT не требуется, ведь нам не зачем товары или категории, которые не имеют URL, по этому, смена JOIN LEFT на INNER JOIN весьма существенно сказывается на производительности, с 90 сек. до 0,2 сек.

Как быстро определить причину слишком медленной работы интернет магазина?

Системы контроля и мониторинга: new relic, tideways. Могу сказать по собственному опыту, что tideways стоит на порядок дешевле, но обладает практически одинаковыми функциями с new relick, который на мой взгляд имеет более дружелюбный UI

Профилирование, тестирование. Использование в работе инструментов для выявления “латентного” кода, позволит выявить не совсем очевидную проблему на ранней стадии и скорее всего будет устранена до момента, когда ее (проблему) обнаружит клиент/пользователь. В своей работе мы используем Blackfire.io Интересные примеры с использованием этого сервиса обязательно появятся в скоро в нашем блоге 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *