Cum să profilați interogările SQL pentru o performanță mai bună

La Servebolt, trăim și respirămperformanță .

Performanța bazei de date nu face excepție.

Executarea unei interogări ineficiente după ce un vizitator al site - ului face clic pe un link va degrada semnificativ experiența utilizatorului .Ei vor trebui să aștepte executarea întregii durate a interogării lente, care poate dura câteva secunde, înainte să aibă loc orice altă acțiune, cum ar fi redarea paginii. Acest timp de așteptare include nu numai timpul necesar pentru rularea interogării, ci și orice timp suplimentar necesar pentru preprocesare și post-procesare. Drept urmare, o interogare prost concepută poate încetini semnificativ performanța generală a unui site web - rezultând o experiență frustrantă pentru utilizator.

Time to First Byte (TTFB) este o modalitate de a măsura cât timp durează până când primul octet de date este primit după ce un utilizator face o solicitare către un site web.Este, de asemenea, o măsură cheie utilizată de motoarele de căutare în evaluarea site-urilor. Când este declanșată o interogare lentă, aceasta va afecta negativ TTFB. Cu cât se execută mai mult interogarea lentă, cu atât TTFB va fi mai mare, rezultând o performanță generală a site-ului web mai lentă și o experiență de utilizator mai puțin satisfăcătoare.

În acest ghid, vă vom prezenta modul de profilare a interogărilor SQL – o parte crucială a menținerii performanței aplicațiilor web care se bazează pe răspunsurile bazei de date. Acesta este un proces care pune bazele pentru a putea începe să lucrăm la optimizarea acestor interogări pentru a le îmbunătăți performanța.

Înțelegerea profilării interogărilor SQL

Pe măsură ce dezvoltați o aplicație web și începe să funcționeze la o scară mai mare, interogările SQL care odată rulau fără probleme pot cauza probleme de performanță. În general, tinde să existe un număr tot mai mare de interogări care rulează pe o cantitate tot mai mare de date, cu un număr tot mai mare de solicitări pe secundă. Și atunci când performanța are de suferit, la fel și experiența pe care o au utilizatorii atunci când interacționează cu site-ul, software-ul sau serviciul dvs.

Profilarea interogărilor este o modalitate de a analiza interogările bazei de date, de a evalua performanța acestora și de a identifica problemele potențiale.

Analizând și identificând aceste interogări problematice, puteți face îmbunătățiri specifice care pot face o diferență măsurabilă în performanța bazei lor de date. Acest lucru va permite, la rândul său, o scalabilitate îmbunătățită în viitor, precum și satisfacția generală a clienților, deoarece aplicațiile și site-urile vor fi mai receptive.

MariaDB (și MySQL) oferă mai multe instrumente și tehnici pentru profilarea interogărilor, pe care le vom acoperi în acest articol. Odată ce interogările lente au fost identificate , următorul pas va fi optimizarea acestora. Acest proces include identificarea cauzei principale a problemei și efectuarea de modificări la structura interogărilor pentru a le îmbunătăți eficiența.

Cum se profilează interogări SQL (7 metode)

Să începem prin a defalca diferitele instrumente și tehnici disponibile pentru a identifica interogările lente și ineficiente, astfel încât să știți unde să concentrați eforturile de îmbunătățire:

1 – ComandaEXPLAIN EXTENDED

Unul dintre instrumentele care pot fi folosite pentru a analiza interogările SQL este comandaEXPLAIN .

Rulând comanda EXPLAIN pe o interogare, puteți vedea cum este executată interogarea, inclusiv ce indici sunt utilizați și numărul de rânduri care sunt examinate.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

Când executați comanda EXPLAINpe o interogare, aceasta returnează un set de rezultate cu mai multe coloane, inclusiv:

• id: identificatorul unic al interogării din planul de execuție
• select_type: tipul interogării, cum ar fi SIMPLE sau SUBQUERY
• table: tabelul care este interogat
• type: tipul de îmbinare utilizat, cum ar fi JOIN sau INDEX
• posibil_keys: indecșii pe care MariaDB sau MySQL i-ar fi putut folosi pentru a procesa interogarea
• cheie: indexul pe care MariaDB sau MySQL l-au folosit de fapt pentru a procesa interogarea
• key_len: lungimea cheii care a fost folosită
• rânduri: numărul de rânduri pe care MariaDB sau MySQL le estimează vor fi examinate pentru interogare

Extra: Acesta conține informații suplimentare despre interogare, cum ar fi dacă a fost efectuată o scanare completă a tabelului sau dacă a fost utilizat un tabel temporar.

Analizând rezultatul comenziiEXPLAIN, în general, puteți identifica potențiale blocaje de performanță, cum ar fi indexarea slabă, tipurile de îmbinare suboptime sau un număr mare de rânduri examinate.

De exemplu, dacă coloana de tip arată „ALL” în loc de „index”,atunci interogarea efectuează o scanare completă a tabelului, ceea ce aproape sigur va duce la o performanță lentă. Dacă coloana cheie este NULL, atunci MySQL nu folosește niciun index, care va fi, de asemenea, lent. Dacă coloana de rânduri are o valoare mare, înseamnă că sunt examinate multe rânduri, ceea ce duce la o degradare suplimentară a performanței.

Preferăm să folosim varianta EXPLAIN EXTENDED pentru a oferi informații suplimentare.

Notă: Deși acest lucru este depreciat în MySQL, este încă disponibil în MariaDB.

Folosind opțiunea EXTENDED, veți putea vedea informații utile, cum ar fi numărul de rânduri examinate, numărul de rânduri returnate, informații despre tipul de JOIN utilizat, ordinea tabelelor scanate, indecșii utilizați și cât timp interogarea a trebuit să fie executată.

Iată cum arată utilizarea comenzii EXPLAIN EXTENDED:

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

În acest exemplu, comanda EXPLAIN va afișa o listă cu pașii pe care baza de date va face pentru a executa interogarea, precum și o listă a resurselor pe care le va folosi.

Folosind această comandă, veți putea identifica mai ușor blocajele în interogare, permițându-vă să faceți orice modificări necesare va ajuta la atenuarea acestui lucru și la accelerarea performanței interogării.

De exemplu, utilizarea comenzii EXPLAIN EXTENDED poate ajuta la identificarea necesității de a adăuga indecși, de a optimiza condițiile JOIN și de a limita numărul total de rânduri returnate de interogare.

De asemenea, ar trebui să vă asigurați că ați dezactivat memorarea în cache a interogărilor atunci când efectuați această testare și optimizări pentru a vă asigura că obțineți rezultate exacte. Pentru a face acest lucru, executați mai întâi această comandă când vă conectați clientul.

SET SESSION query_cache_type=0;

După ce ați făcut aceste modificări la interogarea dvs., testați-i din nou performanța pentru a identifica cât de mult a fost realizată o îmbunătățire (dacă este cazul). Amintiți-vă că, la fel ca în orice profilare și optimizare a unei interogări, procesul este iterativ - așteptați-vă să utilizați comanda EXPLAIN EXTENDED, urmată de un test de performanță, de mai multe ori.

2 – ComandaEXPLAIN ANALYZE

Această comandă este utilizată pentru a analiza planul de execuție al unei interogări și a returna valorile de performanță, cum ar fi timpul real de execuție a interogării și numărul de rânduri pe care le-a examinat efectiv. Analizând rezultatele comenzii EXPLAIN ANALYZE, puteți identifica orice blocaje potențiale în execuția interogării, cum ar fi lipsa de indici sau un număr mare de rânduri care trebuie examinate.

3 – Jurnalul de interogări lente

Aceasta este o caracteristică încorporată în MariaDB (și MySQL) care înregistrează toate interogările care durează mai mult decât o anumită perioadă de timp pentru a se executa. Jurnalul de interogări lente poate fi configurat pentru a înregistra interogări care durează mai mult decât un anumit prag, cum ar fi o secundă.

La Servebolt, jurnalul de interogări lente înregistrează toate interogările care durează mai mult de 1 secundă pentru a se executa. Acest lucru se datorează faptului că majoritatea interogărilor ar trebui să se execute în fracțiuni de secundă. În contextul unei aplicații web, cum ar fi un site care rulează WordPress, încărcarea unei singure pagini necesită între 10 și 100 de interogări de bază de date, toate acestea trebuie executate secvenţial înainte ca pagina să poată fi compilată în HTML și returnată utilizatorului.

Configurația actuală Servebolt Cloud păstrează jurnalele de interogări lente pe un server de jurnal global. Dacă este nevoie, puteți pur și simplu să luați legătura cu echipa noastră de asistență, iar noi vom filtra fișierul pentru jurnalele relevante și vă vom oferi rezultatul.

În propriile medii, puteți activa jurnalul de interogări lente adăugând următoarele linii în fișierul de configurare MariaDB sau MySQL (my.cnf sau my.ini):

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 – Planul de explicație vizuală

Un plan de explicație vizuală oferă o reprezentare grafică a ieșirii comenzii EXPLAIN, facilitând înțelegerea execuției unei interogări și detectarea oricăror probleme de performanță.

Notă: Planurile Visual Explain sunt utile atunci când sunteți în proces de dezvoltare a aplicațiilor web.

În loc de text simplu, afișează execuția interogării într-o structură arborescentă , fiecare nod reprezentând un tabel, index sau operație, iar conexiunile dintre ele descriu ordinea operațiilor.

Diferite instrumente, cum ar fi MySQL Workbench și EXPLAIN Analyzer, pot genera planuri explicative vizuale și oferă o interfață interactivă pentru navigarea planului de execuție și examinarea fiecărei operațiuni în detaliu.

De exemplu, în MySQL Workbench, generarea unui plan de explicație vizuală este la fel de simplă ca executarea interogării și clic pe butonul „Explicare plan ” din fila cu rezultate.Aceasta prezintă o reprezentare grafică a planului de execuție a interogării, împreună cu informații detaliate despre fiecare operație. Acest lucru vă permite să identificați orice probleme de performanță și apoi să optimizați interogarea după cum este necesar.

5 – Tunerul MySQL

MySQL Tuner este un script care verifică performanța și configurația unui server de baze de date și oferă recomandări pentru îmbunătățire. Acesta oferă un rezumat al stării curente a serverului, inclusiv informații precum numărul total de interogări, numărul de interogări lente și utilizarea curentă a pool-ului de buffer.

De asemenea, poate fi folosit pentru a verifica diverse alte setări, cum ar fi versiunea bazei de date, motorul de stocare utilizat și configurația cache-ului de interogări și oferă recomandări pentru optimizarea acestor setări pe baza volumului de lucru curent.

Una dintre principalele diferențe cu alte instrumente este că este un instrument de linie de comandă care poate fi rulat fie pe serverul propriu-zis, fie de la distanță, facilitând automatizarea procesului de monitorizare și optimizare a performanței bazei de date.

Notă: Dacă aplicația dvs. web (și baza de date) sunt deja găzduite în Servebolt Cloud - acesta este ceva în care echipa noastră este specializată și este capabilă să facă mai bine decât orice recomandări pe care le-ar putea oferi un instrument.

6 – Profileri de interogări

Există profileri de interogări terți care pot fi utilizați pentru profilarea interogărilor SQL, cum ar fi MariaDB Enterprise Query Analyzer , Dataedo și Percona Toolkit . Profilerii de interogări terți pot oferi caracteristici și funcționalități suplimentare în comparație cu instrumentele încorporate disponibile în MariaDB (sau MySQL).

Notă: Profilele de interogări sunt utile atunci când sunteți în proces de dezvoltare a aplicațiilor web.

De exemplu, acestea pot oferi informații mai detaliate despre performanța interogărilor, cum ar fi timpii de execuție și timpii de așteptare de blocare și pot oferi vizualizarea datelor în moduri care nu sunt posibile cu instrumentele încorporate.

Dacă instrumentele încorporate sunt suficiente pentru nevoile dvs., atunci nu este nevoie să utilizați profileri de interogări terți. Cu toate acestea, dacă aveți nevoie de informații mai detaliate sau de funcții avansate, atunci ar putea merita să luați în considerare un profiler terță parte.

7 – Profilare cu instrumente de monitorizare

Există, de asemenea, o serie de instrumente de monitorizare, cum ar fi Prometheus, Grafana și Nagios, care pot fi folosite pentru a profila interogări și pentru a monitoriza performanța bazelor de date.

Prometheus este un sistem eficient de monitorizare care poate colecta, stoca și interoga datele de metrică, permițându-vă să obțineți informații valoroase în timp real.Se integrează cu MariaDB (și MySQL) pentru a stoca valorile colectate și vine cu Grafana pentru o vizualizare eficientă.

Grafana este un instrument de analiză puternic, open-source, care poate fi folosit pentru a monitoriza și vizualiza datele colectate de la Prometheus.Configurarea tablourilor de bord și alertelor personalizate vă permite să urmăriți performanța bazei de date în timp real.

Nagios vă ajută să urmăriți starea bazei de date în orice moment.Poate fi configurat pentru a monitoriza resurse cheie, cum ar fi CPU, RAM și spațiu pe disc, ținând în același timp evidența altor servicii și dispozitive de rețea. Deoarece este foarte configurabil, este un instrument excelent pentru monitorizarea proactivă a interogărilor bazei de date.

Cu ajutorul acestor instrumente de monitorizare a serverului, puteți urmări problemele de performanță și puteți lua măsuri rapid, permițându-vă să vă asigurați că serverul dumneavoastră de baze de date funcționează fără probleme.

Tehnici comune de optimizare a interogărilor

Există mai multe tehnici comune de optimizare a interogărilor care pot fi utilizate pentru a îmbunătăți performanța interogărilor SQL:

1 – Indexare

Indexurile sunt o modalitate de a accelera interogările – în special cele care folosesc filtre(UNDE).Utilizarea indexurilor are ca rezultat structuri de date în motorul bazei de date (MariaDB sau MySQL) în afara unor tabele specifice și indică datele pe care încercați să le interogați. Nu vom intra în prea multe detalii în această postare, deoarece utilizarea indecșilor pentru a îmbunătăți interogările bazei de date justifică un articol propriu - ceva ce intenționăm să acoperim în viitor.

De exemplu, luați în considerare un tabel mare numit „comenzi” care conține milioane de rânduri de date, inclusiv informații precum ID-ul comenzii, ID-ul clientului și data comenzii. Dacă se execută o interogare pentru a prelua toate comenzile plasate de un anumit client fără un index în coloana ID client, MariaDB ar trebui să scaneze întregul tabel pentru a localiza datele relevante. Acest lucru ar putea necesita timp și resurse semnificative, în special pentru mesele mari.

În linii mari, ori de câte ori sunteți încrezător că veți rula o anumită interogare în mod repetat și că veți citi chestiuni de performanță, crearea unui index (sau a mai multor index) poate fi abordarea potrivită pentru a accelera respectiva interogare.

În contextul WordPress, acest lucru este foarte comun. O mulțime de plugin-uri sunt create de dezvoltatori care (din comoditate) folosesc tabele generice, partajate, fără a folosi indecși. Drept urmare, este, de asemenea, un domeniu în care există adesea câștiguri de performanță foarte semnificative.

Pentru a vizualiza orice index care există pe un anumit tabel,

Puteți vizualiza orice index care există într-un anumit tabel utilizând SHOW INDEX FROM - cum ar fi în exemplul de mai jos pentru tabelul wp_postmeta:

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

Într-un scenariu, am creat recent doi indecși pentru un tabel wp_postmeta:sb_postid_metakey și sb_postid_metakey_metaval.

Acești indecși au fost adăugați pe baza analizei principalelor interogări lente și a constatat că toate erau relativ similare prin caracteristica de a fi instrucțiuni SELECT care filtrează folosind WHERE în plus față de o mulțime de condiții de comparație (ȘI/SAU). După ce am văzut acest lucru, am revizuit indecșii actuali pentru tabelul utilizat și am rulatEXPLAIN EXTENDED pe interogare pentru a valida mai departe abordarea mea.

Interogarea a funcționat în cea mai mare parte și a folosit tabelul wp_postmeta folosindJOIN.Pe baza ordinii în care s-a întâmplat acest lucru, adăugarea acestor indecși ar permite lui MariaDB (sau MySQL) să obțină răspunsul de la indecși în loc să scaneze întregul tabel cu toate rândurile sale.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

Aceasta este o combinație a „descoperirii lucrurilor” prin utilizarea instrumentelor pe care le aveți la dispoziție (după cum s-a subliniat mai sus), precum și cunoașterea tipurilor de date și a conținutului bazei de date. Acest lucru nu funcționează întotdeauna; chiar și atunci când se întâmplă, nu întotdeauna duce la o îmbunătățire a performanței cu 500%. A avea un index uriaș poate ajunge să fie mai lent decât scanarea tuturor rândurilor, așa că interogările trebuie testate înainte și după aplicarea indicilor pentru a fi sigur.

Notă: când încercați să testați vitezele de indexare, veți dori să dezactivați memorarea în cache a interogărilor pentru sesiune, folosind:

SET SESSION query_cache_type=0;

În acest caz, înainte de a utiliza indecși, interogarea a durat 10,437 secunde pentru a se executa. Și după crearea celor doi indici, aceeași interogare a durat [# de secunde].

2 – Reducerea accesului la date

Reducerea accesului la date , adică reducerea la minimum a numărului de rânduri și coloane care urmează să fie accesate pentru a executa o interogare.Acest lucru poate fi realizat prin filtrarea datelor care sunt preluate de interogare, folosind indecși și partiționând tabele mari. Deși nu este ceva ce majoritatea oamenilor vor avea nevoie (sau vor putea) să facă, este un punct esențial de reținut atunci când proiectați interogări de baze de date de la zero.

De exemplu, dacă o interogare de bază de date caută date despre un utilizator în scopuri de conectare, interogarea ar trebui să fie LIMIT 1, deoarece în mod clar nu ar trebui să fie niciodată necesare mai mult de date ale unui utilizator.

Notă: Acest lucru se referă mai mult la proiectarea bazei de date decât la optimizare.Deși este important pentru menținerea performanței, acest efort este mai relevant pentru dezvoltatorii de pluginuri (în contextul WordPress) decât pentru majoritatea utilizatorilor finali.

Amintiți-vă că, înainte de a testa vitezele după efectuarea oricăror modificări la accesul la date, ar trebui să vă asigurați că ați dezactivat memorarea în cache a interogărilor, rulând următoarea comandă:

SET SESSION query_cache_type=0;

3 – Utilizarea partiționării datelor

Prin partiționarea datelor în bucăți mai mici, bazele de date devin mai eficiente și necesită mai puțin timp de administrat. Această strategie poate ajuta la reducerea timpului petrecut cu procesele de întreținere, cum ar fi backup-urile și actualizările, precum și limitarea cantității de date care trebuie gestionate. În general, ajută la îmbunătățirea performanței și la optimizarea utilizării resurselor.

Pentru a partiționa datele într-o bază de date, puteți urma acești pași:

1. Când selectați un tabel pentru a fi partiționat, asigurați-vă că alegeți unul care să dețină o cantitate mare de date și care ar beneficia de împărțirea. Acest lucru va ajuta la optimizarea sistemului și la îmbunătățirea performanței interogărilor.
2. Selectarea metodei de partiţionare potrivite pentru baza de date este crucială. Puteți alege dintre intervale, listă, hash sau partiționare cheie – în funcție de structura datelor și de interogările pe care intenționați să le executați. Asigurați-vă că îl alegeți pe cel care se potrivește cel mai bine nevoilor dvs. pentru performanță și rezultate optimizate.
   
   1. Partiționarea intervalului este alegerea ideală atunci când aveți date care pot fi împărțite în anumite intervale.De exemplu, dacă aveți un tabel cu date pentru mai mulți ani, puteți crea o partiție de interval pentru a o organiza mai bine. S-ar putea baza pe data sau pe valoarea numerică a coloanei în cauză.
   2. Partiționarea listelor este o tehnică eficientă pentru a gestiona datele care pot fi ușor separate în diferite grupuri, conform unui anumit parametru.De exemplu, aveți un tabel cu informațiile angajaților clasificate pe departament; aceasta necesită utilizarea partiționării listelor.
   3. Partiționarea hash este o strategie eficientă pentru aranjarea datelor în clustere de dimensiuni egale pe baza valorii hash a unei anumite coloane.Acest lucru permite o distribuție uniformă a datelor pe mai multe partiții, ceea ce o face o alegere excelentă pentru distribuirea eficientă a datelor.
   4. Partiționarea cheii este similară cu partiționarea hash, dar diferența majoră este că folosește o anumită valoare de coloană ca bază pentru împărțirea datelor în diferite grupuri.Acest lucru îl face o alegere ideală pentru seturile de date care pot fi împărțite în grupuri separate pe baza unui identificator unic sau a unei chei naturale.
3. Prin crearea unui tabel partiționat, puteți împărți efectiv tabelul original în altele mai mici. Acest lucru se realizează prin adăugarea unei clauze de partiționare în instrucțiunea CREATE TABLE, unde specificați metoda și condițiile dorite pentru segmentare. Acest lucru poate ajuta la îmbunătățirea performanței interogărilor și, de asemenea, poate face gestionarea datelor mai eficientă.
4. Puteți copia rapid datele din tabelul original în cel nou partiționat folosind instrucțiunea INSERT INTO... SELECT. Acest lucru va popula cu ușurință tabelul dvs. partiționat cu toate informațiile relevante.
5. Aplicațiile trebuie acum reconfigurate pentru a profita de tabelul partiționat. Acest lucru va înlocui tabelul original și va face aplicațiile dvs. mai eficiente.
6. Înainte de a rula orice test pentru a evalua potențiala îmbunătățire a performanței, va fi esențial să dezactivați mai întâi memorarea în cache a interogărilor, rulând comanda: SET SESSION query_cache_type=0;
7. Pentru a vă asigura că masa dvs. partiționată funcționează fără probleme, este important să urmăriți cu atenție performanța acesteia. Dacă observați probleme, ajustarea condițiilor de partiționare sau trecerea la o altă metodă ar putea ajuta. Monitorizarea regulată a partițiilor vă va ajuta să le maximizați potențialul.

Notă importantă despre actualizările de scripturi și tabelele partiționate

Deși partiționarea bazelor de date poate face o diferență pozitivă în ceea ce privește eficiența, este important să țineți cont de potențialele probleme cauzate de rularea scripturilor de actualizare pentru a schimba schema bazei de date. Este esențial ca tabelele partiționate să fie luate în considerare atunci când scriptați aceste upgrade-uri. Dacă tabelele partiționate nu sunt luate în considerare în scripturile de actualizare, ar putea exista probleme potențiale care vor duce aproape sigur la o funcționare defectuoasă a site-ului.

De exemplu, dacă un script este creat pentru a adăuga o nouă coloană la un tabel partiționat, acesta ar putea modifica doar o partiție, creând inconsecvențe și probleme în cadrul datelor. De asemenea, dacă un script de actualizare este creat pentru a adăuga un index la o tabelă partiționată, acesta poate genera indexul doar pe o partiție, rezultând performanțe mai lente și rezultate inconsecvente.

Pentru a evita astfel de probleme, scripturile de upgrade trebuie să fie concepute pentru a lua în considerare tabelele partiționate. Acest lucru ar putea implica rularea scriptului pe fiecare partiție individual sau revizuirea scripturilor pentru a funcționa cu tabele partiționate. De asemenea, este important să efectuați teste amănunțite pentru a vă asigura că procesul de actualizare nu generează probleme neașteptate sau pierderi de date.

4 – Redis

Pentru clienții Servebolt, Redis este un supliment (plătit) care poate ajuta la optimizarea interogărilor.

Redis (uneori cunoscut sub numele de Remote Dictionary Server) este o soluție open-source care stochează date în memorie și poate fi folosită pentru stocarea în cache, o bază de date sau chiar ca broker de mesaje. Poate fi integrat cu o bază de date pentru a îmbunătăți performanța, acționând ca un intermediar eficient între aplicație și baza de date.

Funcționează pentru a îmbunătăți performanța și timpii de răspuns ai aplicațiilor prin reducerea încărcării bazei de date. Acest lucru se realizează prin stocarea datelor utilizate frecvent în Redis în loc de baza de date pentru fiecare solicitare, economisind astfel timp considerabil.

Prin configurarea corectă a pluginului, Redis poate fi utilizat cu o bază de date pentru optimizarea execuției interogărilor. Când datele necesare nu sunt prezente în Redis, aplicația le va prelua din baza de date și le va stoca în Redis pentru utilizare ulterioară. Acest lucru face ca recuperarea datelor să fie mult mai rapidă și mai eficientă.

Folosind această abordare, aplicația poate beneficia de accesul rapid în memorie al Redis și, de asemenea, poate stoca și accesa datele din baza de date după cum este necesar.

Rețineți că, dacă implementați Redis pentru prima dată, va trebui să dezactivați interogarea cache înainte de a rula orice teste de performanță. Pentru a face acest lucru, utilizați comanda:

SET SESSION query_cache_type=0;

Concluzie

Ecosistemul MariaDB și MySQL are o gamă largă de instrumente și metode pentru a facilita descoperirea blocajelor în execuțiile interogărilor bazei de date, permițându-vă să îmbunătățiți performanța aplicațiilor dvs. web.

Este probabil să apară încetiniri pe toată durata rulării oricărei aplicații. Încercarea de a le evita este grozavă, dar în cele din urmă trebuie să știi unde să te uiți atunci când începi să diagnosticezi problemele de performanță. În funcție de dimensiunea și natura bazelor de date pe care le executați, acesta este un proces iterativ care necesită monitorizare continuă, depanare și îmbunătățire continuă pentru a vă menține bazele de date la un standard ridicat.