При оптимізації проектів, практично всі запити переписуються заново. З'ясовуються найвужчі місця і самі великовагові запити і розбираються по дрібницях. Розглядаються різні варіанти перебудови запитів таким чином, щоб забезпечити найкращу швидкодію при найменших витратах часу і ресурсів.
Самі "неправильні" запити MySQL
При цьому запиті вибираються все-все дані 100 рядків з гігантською табліци- навіщо? У 99% потрібно вибрати тільки потрібні стовпці, але "умілі" програмісти, пишуть саме так. На додаток до всього - ця таблиця ще й буде сортуватися - чому? Так, тому, що явно не вказано: ORDER BY NULL.
Уявіть, що в цій таблиці 42 стовпчика, 20 з яких `text` і одночасних звернень до таблиці в піки навантаження буває до 100. Уявляєте які обсяги непотрібної інформації сервер ганяє" даремно "?
Що в цьому запиті не так? Так вобщем-то все нормально, якщо ним користуватися для MyISAM таблиць. Справа в тому що таблиці в цьому типі зберігання зберігають кількість записів безпосередньо в самій таблиці і тому результат ми отримуємо миттєво.
Зовсім інша ситуація з InnoDB таблицями. Там, в залежності від навантаження на сервер і розміру таблиці, запит може виконуватися дуже і дуже довго. Для InnoDB:
Слід розуміти що у кожного типу зберігання свої переваги і намагатися домогтися підвищення продуктивності просто зміною цього типу щонайменше наївно. Щось дійсно запрацює швидше, наприклад одночасна модифікації таблиці в InnoDB проти того ж в MyISAM. а щось заробить повільніше. Якщо прийнято рішення про зміну формату зберігання даних, потрібно уважно вивчити всі запити до бази і затюніть їх з урахуванням майбутнього зміни. Цілком можливо доведеться міняти всю архітектуру сервісу.