La optimizarea proiectelor, aproape toate solicitările sunt re-scrise. Blocajele și cele mai dificile interogări sunt clarificate și sunt sortate în detaliu. Considerăm toate opțiunile posibile pentru reconstruirea interogărilor astfel încât să se asigure cea mai bună performanță cu cel mai mic timp și resurse.
Cele mai greșite interogări MySQL
Cu această interogare, toate cele 100 de rânduri din tabelul gigant sunt selectate - de ce? În 99% trebuie să selectați doar coloanele de care aveți nevoie, dar programatorii "pricepuți" scriu în acest fel. În afară de tot - acest tabel va fi, de asemenea, sortat - de ce? Da, deoarece nu este specificat explicit: ORDER BY NULL.
Imaginați-vă că în acest tabel există 42 de coloane, dintre care 20 "text" și apeluri simultane la masă în încărcăturile de vârf sunt de până la 100. Vă puteți imagina ce cantități de informații inutile le pierde serverul?
Ce este în neregulă cu această solicitare? Da, în general, este OK, dacă îl utilizați pentru tabelele MyISAM. Faptul este că tabelele din acest tip de stocare stochează numărul de înregistrări direct în tabel și astfel rezultatul este instantaneu.
O situație complet diferită cu mesele InnoDB. Acolo, în funcție de încărcarea pe server și dimensiunea tabelului, interogarea poate fi executată foarte, foarte lungă. Pentru InnoDB:
Trebuie să se înțeleagă că fiecare tip de depozitare are avantaje proprii și încearcă să obțină o creștere a productivității prin simpla schimbare a acestui tip cel puțin naiv. Ceva va funcționa mai repede, de exemplu actualizarea simultană a tabelului în InnoDB împotriva aceluiași în MyISAM. dar ceva va funcționa mai lent. Dacă decideți să schimbați formatul de stocare a datelor, trebuie să examinați cu atenție toate solicitările către baza de date și să le restrângeți în lumina schimbării viitoare. Este posibilă schimbarea întregii arhitecturi a serviciului.
Trimiteți-le prietenilor: