Оптимизация MySQL запросов: практика

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

Итак, имеем скрипт на PHP, который, подключается к базе данных с товарами, производит сложную выборку и выводит её на экран. В итоге получается эмуляция файла yml (xml) для яндекс маркета. Скрипт работал себе нормально, пока заказчик не попросил меня расширить список передаваемых параметров в прайс для маркета.

Сделать это оказалось несложно, несколько запросов и, вуаля, обновленный прайс, в котором учитываются размеры, sales_notes и другое, готов! Но тут возникает проблема: скрипт успешно справлялся с тем количеством товаров и характеристик, но сейчас при нагрузке начинает выдавать ошибку 504. Маловато памяти или долго выполняется (или и то и другое одновременно).



Что ж, пытаемся скрипт оптимизировать. Начнем со своей части. Все запросы типа

SELECT param_value FROM `le_items_params` WHERE  `item_id` = '".$value['id']."' AND `param_id` = '240'

Снабжаем дополнительно LIMIT 1. Вы не поверите, но эта простая мера в два раза ускорила выполнения скрипта! Кстати, для проверки времени, можно использовать это:

$start = microtime(true);
//запросы к базе
$time = microtime(true) - $start;
printf('<!--Скрипт выполнялся %.4F сек.-->', $time);

Далее смотрим в сторону тяжелых запросов LEFT JOIN и убираем из них все ORDER BY i.id. И на самом деле: какая нам разница, в какой последовательности товары будут в прайсе – все равно они потом на сайте яндекс маркета займут свое полагающееся место.

Далее смотрим интересный момент. В исходном скрипте идет формирование переменной типа string, которая потом выводится на экран (как я и говорил, эмулируется файл yml). И все опции товаров записываются в одну эту переменную! Понятно, что память не резиновая и когда-то приходит ей конец. Изменяем все это на вывод сразу в браузер – еще немного экономим.

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

Напоминаю, что если у вас есть вопросы по PHP, MySQL и сайтам вообще, то вы в любое время можете обратиться ко мне – за небольшую плату я вам с удовольствием помогу в решении любых проблем, связанных с сайтами, CMS, программированием.
заметки, mysql, php, практика, оптимизация