При оптимизации проектов, практически все запросы переписываются заново. Выясняются самые узкие места и самые тяжеловесные запросы и разбираются по мелочам. Рассматриваются всевозможные варианты перестраивания запросов таким образом, чтобы обеспечить наилучшее быстродействие при наименьших затратах времени и ресурсов.
Самые "неправильные" запросы MySQL
SELECT * FROM `where_big_tabe` WHERE `hide`>0 LIMIT 100;При этом запросе выбираются все-все данные 100 строк из гигантской таблицы- зачем? В 99% нужно выбрать только нужные столбцы, но "умелые" программисты, пишут именно так. В добавок ко всему - эта таблица еще и будет сортироваться - почему? Да, потому, что явно не указано: ORDER BY NULL.
Представьте, что в этой таблице 42 столбца, 20 из которых `text` и одновременных обращений к таблице в пики нагрузки бывает до 100. Представляете какие объемы ненужной информации сервер гоняет "впустую"?
SELECT COUNT(*) FROM `where_big_tabe`;Что в этом запросе не так? Да вобщем-то все нормально, если им пользоваться для MyISAM таблиц. Дело в том что таблицы в этом типе хранения хранят количество записей непосредственно в самой таблице и потому результат мы получаем мгновенно.
Совершенно другая ситуация с InnoDB таблицами. Там, в зависимости от нагрузки на сервер и размера таблицы, запрос может выполняться очень и очень долго. Для InnoDB:
SELECT COUNT(`id`) FROM `where_big_tabe`;Следует понимать что у каждого типа хранения свои преимущества и пытаться добиться повышения производительности просто сменой этого типа по меньшей мере наивно. Что-то действительно заработает быстрее, например одновременная модификации таблицы в InnoDB против того же в MyISAM, а что-то заработает медленнее. Если принято решение о смене формата хранения данных, нужно внимательно изучить все запросы к базе и затюнить их с учетом предстоящего изменения. Вполне возможно придется менять всю архитектуру сервиса.
