Когато оптимизиране на проекти, почти всички искания трябва да бъдат преначертани. Изследва най-тесните места и най-тежките разследвания и разгледани дреболии. Помислете за всички възможни варианти възстановяване искания, така че да се осигури най-доброто представяне на най-ниските разходи и време ресурси.

само "грешни" Заявките за най MySQL

В тази заявка избира всички линиите за данни 100 на гигантски трапезен защо? На 99% е необходимо да изберете само колоните, но "сръчни" програмистите пишат по този начин. В допълнение към всичко - тази таблица също ще бъдат сортирани - защо? Да, защото това е изрично посочено: ORDER BY NULL.
Представете си какво се случва с 100. Можете ли да си представите какво количество ненужна информация сървърни дискове "прахосани" в графата за маса 42, 20 от които `text` и едновременни достъпи до масата в пиковите натоварвания?

Че това искане не е тя? Да, по принцип, тогава всичко е наред, ако се използва за MyISAM таблици. Фактът, че таблиците в този тип магазин броя на записите, съхранявани директно в таблицата, и по тази причина са резултат получаваме веднага.
А съвсем друго положение с InnoDB таблици. Там, в зависимост от натоварването на сървърите и големината на масата, заявката може да се направи много, много дълго време. За InnoDB:

Трябва да се разбере, че всеки тип предимства за съхранение и да се опитаме да се постигне по-добра ефективност на този вид промяна най-малко наивен. Нещо наистина работи по-бързо, като едновременно изменение на маса в InnoDB срещу едни и същи във MyISAM. и нещо се по-бавно. Ако сте решили да промените формата на съхранение на данни, което трябва внимателно да разгледа всички заявки към базата данни и zatyunit им с оглед на предстоящото промяната. Доста вероятно ще трябва да се промени цялата структура на услуги.