ātrdarbība MySQL vs PHP

[tomaac]

Interesē - vai kāds ir pētījis, kas ir ātrāk - veikt pieprasījumus ar tīro MySQL vai arī papildināt to ar PHP, vai arī - atkarīgs no situācijas.

 

Piemēram, es varu uzreiz vienā selektā sajoinot divas tabulas un iegūt rezultātus. Tad tas ir tīrais MySQL. Bet varu arī vispirms atselektēt visu no vienas tabulas. Un tad rakstīt jaunu selektu jau šiem esošiem datiem.

 

piemēram, select * from tab1 left join tab2 on tab1.id = tab2.id vai

 

select id, ... from tab1

cikls pa iegūtiem datiem, kur iekšā katram ierakstam $row pildām select * from tab2 where id = $row['id']

[Roze]

To tev neviens nepateiks jo tas atkarīgs no katra gadijuma atsevišķi.

 

Ja izvelk divus vispārīgus gadijumus tad ar PHP ātrāk varētu būt ja pie lielas tabulas joino mazu tabulu. Teiksim ir tabula 'ieraksti' kurā ir id | kategorijas_id un tabula 'kategorijas' kurā ir kategorijas_id | kategorijas_nosaukums. Tagad ja tu selectētu visus ierakstus (teiksim miljons) un joinotu klāt kategoriju lai dabūtu kategorijas nosaukumu sanāktu ka tu miljons reižu selectētu varbūt kādus 10 dažādus kategoriju nosaukumus.. Pretēji tam lai vienkārši ar PHP noselectētu tos 10 ierakstus no kategorijām, saliktu masīvā un izvadītu pie konkrētajiem ierakstiem.

 

 

Ar php nav iespējams ja JOINs notiek starp divām lielām tabulām.. (proti lai nolasītu vienu tabulu sanāktu patērēt daudz resursu) Tad tīri SQL ir labāk.

[Gints Plivna]

Cikls ciklā jebkurā programmēšanas vaodā/vidē, ja vien tam nav ļoti speciāla pamatojuma, ir ātrdarbības killeris. Cikls ciklā kur lasa pa vienam ierakstam un katram no tiem izpilda jaunu SQL teikumu, vispārīgā gadījumā ir šausmas, jo:

1) priekš katra sql teikuma ir jādzenājas pa tīklu vismaz vienreiz vienādi/otrādi;

2) DBVS ir jāsaprot padotais SQL teikums, un jāveic vismaz kaut kādas darbības atkal un atkal, piemēram, lietojot MySQL profileri var redzēt, ka pat iekešotam vaicājumam ir jāveic pārbaude vai tam ir rezultāti kešā, vai tam ir tiesības uz to, utt. (pēdējais show profiles piemērs, kur to pašu vaicājumu izpilda vēlreiz)

3) Nemaz nerunājot par tādiem sīkumiem kā to, ka ārējā cikla sākumā iekšējā tabulā bija vieni dati, bet ārējā cikla beigās iekšējā tabulā dati jau ir citi gan vienam un tam pašam ierakstam, gan iespējams kādi ieraksti jau padzēsti utml. Šeit vajadzētu atcerēties, ka parasti ir vairāklietotāju režīms, nevis es viens pats esmu karalis visā bāzē.

 

Datubāzes ir paredzētas lai veidotu savienojumus tajās un vispirms ir jāpārliecinās un jānoskaidro iemesls, kapēc šajā ļoti speciālajā gadījumā savienojumu nevar veidot datubāzē.

 

BET runājot par iepriekšējo - ir lieta ko var darīt. Tas ir nevis, kad veido ciklu ciklā, bet kad vienreiz masīvā ielasa klasifikatorus utml mazas tabuliņas, kuru vērtības pēc tam nevis lasa miljons reižu atkal un atkal no DB, bet iekešo kādā atslēgu masīvā un tad pēc atslēgas vērtības dabū pa taisno. Tas varētu būt izdevīgi...

 

Jā un vēl tāds sīkums, kad MySQLs implementēs kādu citu join algoritmu izņemot nested loops (atceramies ka vēl ir vismaz hash joins, merge joins), tad arī lielu datu kopu joinošana tajā būs vēl izdevīgāka nekā pašreiz.

 

Gints Plivna

http://datubazes.wordpress.com

[Delfins]

smagais joins vienmēr atmaksāsies. Vismaz uz lielām tabulām.

pārbaudīts praksē :)