Пессимизация

Руковожу хостингом одной некрупной, но гордой компании. Перлов при работе с клиентами много, но больше бывает при общении с разработчиками.

Решили мы тут озаботится вопросом, не расширить ли парк серверов баз данных — ресурсы есть, но нужно ли? Стали собирать статистику. Самым большим по количеству (75%) и объёму (90%) запросов оказался сайт Самого Важного Клиента, который занимал чуть ли не половину дискового пространства всего хранилища и отвечал за 60% всего трафика. Решили посмотреть, что они такое туда пишут.

Оказалось, разработчики этого чуда решили оптимизировать SQL-запросы и использовали какую-то чудо-библиотеку, которая на лету оптимизировала обращения к MySQL-кластеру. Результат оптимизации выглядел следующим образом: сначала происходит обращение на сервер с целью создания физического плана запроса, ждёт подтверждения, затем в него подсовываются входные параметры, забирается результат, но тут происходит самое страшное — физический план запроса удаляется. То есть при каждом однотипном запросе физический план создаётся заново. Но и это не самое страшное. Половина всех запросов выглядела так:

INSERT INTO `statistic_logs` VALUES ...

В результате простейший запрос, занимающий одну строку и являющийся элементарной операцией MySQL-сервера, после «оптимизации» занимал восемь строк и выполнялся в полтора раза медленнее.