Metode de imbunatatiri ale interogarilor SQL
Moderatori: Zamolxe, Moderatori
nu e adevarat. Probabil nu te-ai lovit de situatii mai complexe. Daca faci 2 selecturi, din start ai pierdut timp, apoi pierzi timp cu procesarea primului select si folosirea datelor din primul ca sa-l construiesti pe al doilea...etc. Pe cand cu JOIN ai rezultatul dorit intr-un singur recordset, iar in plus si mai rapid.
Am gasit cateva metode de imbunatire, care in mare parte tine si de server cat si despre felul cum omul face interogarea...
In primul rand e bine ca permisiunile pentru acel server MySQL sa fie lipsite de complexitate (cine a avut ocazia, cred ca a observat ca poti face sa dai unui utilizator acces numai de citire, numai pe o tabela sau numai pe o baza de date etc). Ingreuneaza functionalitatea serverului, proportional si viteza de reactie a serverului la interogarile date.
Utilizarea extensiilor de interogare ca SQL_BUFFER_RESULT si SQL_SMALL_RESULT poate ajuta foarte mult imbunatatirea interogarii.
Din cate am inteles eu, SQL_BUFFER_RESULT forteaza ca rezultatul interogarii sa fie pus intr-o tabela temporara, asta face ca MySQL sa poata trece la urmatoarea interogare mult mai rapid, in timp ce el proceseaza pe cea temporara. Poate gresesc dar cam asta am inteles, si, deduc din acest lucru ca e foarte buna pentru cei care au interogari ce sunt accesate de un numar mare de utilizatori, astfel delay-ul pentru fiecare client scade.
Pentru SQL_SMALL_RESULT poate fi folosit cu GROUP si DISTINCT pentru a anunta serverul ca rezultatul e de marime mica, si in cazul acesta MySQL foloseste tabele mici temporare pentru a stoca rezultatele, in loc sa faca sortarea. Aici nu prea inteleg ce vrea sa zica, astept comentarii de la cei care folosesc uzual asa ceva.
Dupa update-uri cu numar mare de inserari, stergeri sau update-uri e bine sa fie rulata comanda: OPTIMIZE TABLE `tabela` ..... Eu cred ca am sa fac lucrul asta cam la fiecare tabela, in mare parte pentru ca majoritatea tabelelor cu care lucrez in ultima vreme depasesc 1.000 de inregistrari, altele chiar 100.000 de mii.. si tot acest frecus se face undeva in 20 de minute... Astfel ca inca 1 min nu cred ca face rau, mai ales ca am facut un OPTIMIZE pe un tabel cu vizite cu 3.000 de inregistrari si 9 campuri, iar comanda a durat 0,344 conectat de acasa pe serverul SQL de la munca... Asta inseamna ca nu e ceva mult...
Inca o metoda in interogarile de tip SQL_CACHE.
Am probat pentru cateva tabele in care am JOIN a cel putin 3 tabele si nu prea se simte diferenta, poate chiar in unele cazuri a luat mai mult sa faca interogarea, si pe langa asta query_cache_size a ajuns cam rapid undeva la 16 MB, intr-un fel asta ar trebui sa-mi atraga putin atentia.... Daca cineva stie mai multe despre acest lucru, rog sa se intervina..
Comentati la ce am zis, cine stie ceva concret sa spuna, pentru ca eu am scris doar din teorie si prea putin practica la asa ceva...
E bine ca cineva are de invatat de aici Quber.
In primul rand e bine ca permisiunile pentru acel server MySQL sa fie lipsite de complexitate (cine a avut ocazia, cred ca a observat ca poti face sa dai unui utilizator acces numai de citire, numai pe o tabela sau numai pe o baza de date etc). Ingreuneaza functionalitatea serverului, proportional si viteza de reactie a serverului la interogarile date.
Utilizarea extensiilor de interogare ca SQL_BUFFER_RESULT si SQL_SMALL_RESULT poate ajuta foarte mult imbunatatirea interogarii.
Din cate am inteles eu, SQL_BUFFER_RESULT forteaza ca rezultatul interogarii sa fie pus intr-o tabela temporara, asta face ca MySQL sa poata trece la urmatoarea interogare mult mai rapid, in timp ce el proceseaza pe cea temporara. Poate gresesc dar cam asta am inteles, si, deduc din acest lucru ca e foarte buna pentru cei care au interogari ce sunt accesate de un numar mare de utilizatori, astfel delay-ul pentru fiecare client scade.
Pentru SQL_SMALL_RESULT poate fi folosit cu GROUP si DISTINCT pentru a anunta serverul ca rezultatul e de marime mica, si in cazul acesta MySQL foloseste tabele mici temporare pentru a stoca rezultatele, in loc sa faca sortarea. Aici nu prea inteleg ce vrea sa zica, astept comentarii de la cei care folosesc uzual asa ceva.
Dupa update-uri cu numar mare de inserari, stergeri sau update-uri e bine sa fie rulata comanda: OPTIMIZE TABLE `tabela` ..... Eu cred ca am sa fac lucrul asta cam la fiecare tabela, in mare parte pentru ca majoritatea tabelelor cu care lucrez in ultima vreme depasesc 1.000 de inregistrari, altele chiar 100.000 de mii.. si tot acest frecus se face undeva in 20 de minute... Astfel ca inca 1 min nu cred ca face rau, mai ales ca am facut un OPTIMIZE pe un tabel cu vizite cu 3.000 de inregistrari si 9 campuri, iar comanda a durat 0,344 conectat de acasa pe serverul SQL de la munca... Asta inseamna ca nu e ceva mult...
Inca o metoda in interogarile de tip SQL_CACHE.
Am probat pentru cateva tabele in care am JOIN a cel putin 3 tabele si nu prea se simte diferenta, poate chiar in unele cazuri a luat mai mult sa faca interogarea, si pe langa asta query_cache_size a ajuns cam rapid undeva la 16 MB, intr-un fel asta ar trebui sa-mi atraga putin atentia.... Daca cineva stie mai multe despre acest lucru, rog sa se intervina..
Comentati la ce am zis, cine stie ceva concret sa spuna, pentru ca eu am scris doar din teorie si prea putin practica la asa ceva...
E bine ca cineva are de invatat de aici Quber.
Viata e prea scurta sa faci un lucru singur. Cere AJUTOR!
Cod: Selectaţi tot
#!/bin/bash
tabela=tabela
querry=select
pk=primary key
echo "$querry dintr-o $tabela dupa campurile declarate $pk este mult mai rapid"
-
mihaitha
- Senior Member
- Mesaje: 2383
- Membru din: Vin Mai 04, 2007 12:40 pm
- Localitate: Sibiu
- Contact:
bash:
1. ce ai spus tu aici s-a spus deja in mod repetat si din primele posturi.
2. modul tau de a posta ceva, chiar daca o fi inedit, e enervant si greoi de citit. Incearca sa te abtii. Puteam si eu sa postez in coduri ascii, dar m-am abtinut. Stii de ce? Pentru ca atunci cand postez eu ceva, eu stiu ce am vrut sa scriu, si ceilalti trebuie sa poata citi ce am scris eu, altfel n-ar avea nici un rost sa postez. Te rog sa te abtii de la chestia asta ca incepi sa ma seci, si sunt sigur ca nu sunt singurul.
1. ce ai spus tu aici s-a spus deja in mod repetat si din primele posturi.
2. modul tau de a posta ceva, chiar daca o fi inedit, e enervant si greoi de citit. Incearca sa te abtii. Puteam si eu sa postez in coduri ascii, dar m-am abtinut. Stii de ce? Pentru ca atunci cand postez eu ceva, eu stiu ce am vrut sa scriu, si ceilalti trebuie sa poata citi ce am scris eu, altfel n-ar avea nici un rost sa postez. Te rog sa te abtii de la chestia asta ca incepi sa ma seci, si sunt sigur ca nu sunt singurul.
bash, decode this:
Cod: Selectaţi tot
echo chr(98), chr(97), chr(115), chr(104), chr(44), chr(32), chr(101), chr(115), chr(116), chr(105), chr(32), chr(116), chr(97), chr(114), chr(101), chr(32), chr(99), chr(97), chr(32), chr(115), chr(116), chr(105), chr(105), chr(32), chr(98), chr(97), chr(115), chr(104), chr(33), chr(32), chr(80), chr(97), chr(110), chr(97), chr(32), chr(117), chr(110), chr(97), chr(32), chr(97), chr(108), chr(116), chr(97), chr(32), chr(102), chr(105), chr(105), chr(32), chr(116), chr(101), chr(32), chr(114), chr(111), chr(103), chr(32), chr(117), chr(109), chr(97), chr(110), chr(46), chr(32), chr(83), chr(116), chr(105), chr(109), chr(32), chr(115), chr(105), chr(32), chr(110), chr(111), chr(105), chr(32), chr(115), chr(97), chr(32), chr(111), chr(98), chr(102), chr(117), chr(115), chr(99), chr(97), chr(109), chr(32), chr(109), chr(101), chr(115), chr(97), chr(106), chr(101), chr(46), chr(32), chr(80), chr(111), chr(97), chr(116), chr(101), chr(32), chr(112), chr(114), chr(105), chr(110), chr(32), chr(109), chr(101), chr(116), chr(111), chr(100), chr(101), chr(32), chr(109), chr(97), chr(105), chr(32), chr(105), chr(110), chr(103), chr(101), chr(110), chr(105), chr(111), chr(97), chr(115), chr(101), chr(32), chr(100), chr(101), chr(99), chr(97), chr(116), chr(32), chr(116), chr(105), chr(110), chr(101), chr(46), chr(32), chr(77), chr(117), chr(108), chr(116), chr(117), chr(109), chr(101), chr(115), chr(99);
Scuze.Nu am nici o legatura cu mandriva2007.Recent m-am mutat intr-o garsoniera unde stau cu chirie,nefiind din Bucuresti.Simplu face un array corespunzator fiecarui caracter ascii,iar apoi cu strstr iti covertesti textul in ascii .ex :chr(103)>g.
Ultima oară modificat Dum Aug 24, 2008 4:51 pm de către bash, modificat 1 dată în total.
bash scrie:Scuze.Nu am nici o legatura cu mandriva2007.Recent m-am mutat intr-o garsoniera unde stau cu chirie,nefiind din Bucuresti.
Offtopic: asta te face deosebit in vreun fel, sau nu imi dau eu seama?
Pe langa asta, ai un mod ratat total de a face posturi.
Ontopic: in principal, un query rapid e un query facut cu cap.
Select * FROM table e mai lent decat Select `camp1,`camp2` FROM `table`
Nu e vorba de deosebit,era un raspuns la o intrebare pusa de mihaitza.
E mai lent decat :
PS Mi-am cerut scuze pentru modul ratat.
E mai lent decat :
Cod: Selectaţi tot
select camp1, camp2 from tabela mea where camp1='value1' and camp2='value2'
PS Mi-am cerut scuze pentru modul ratat.
-
mihaitha
- Senior Member
- Mesaje: 2383
- Membru din: Vin Mai 04, 2007 12:40 pm
- Localitate: Sibiu
- Contact:
Tocmai afirmatia asta ma face sa te suspectez si mai rau. mandriva n-a zis niciodata ca ar fi din Bucuresti. In plus, sunt o gramada de chestii in comun intre astia doi: mandriva n-a fost in stare sa bage la cap ca user-ul meu e mihaitha, nu mihaitza, contul bash e creat exact in ziua in care mandriva a luat ban etc.bash scrie:Scuze.Nu am nici o legatura cu mandriva2007.Recent m-am mutat intr-o garsoniera unde stau cu chirie,nefiind din Bucuresti.
Cine este conectat
Utilizatori ce ce navighează pe acest forum: Niciun utilizator înregistrat și 23 vizitatori