DevProTalk
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

DevProTalk (http://www.devprotalk.com/index.php)
-   SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)
-   -   mySQL prepared statement (http://www.devprotalk.com/showthread.php?t=5588)

bluesman 12. 06. 2008. 14:53
mySQL prepared statement
 
Kada se pripremi i izvrsi statement, na primer:

PREPARE test FROM 'SELECT email FROM users WHERE id=?';
SET @u = 123;
EXECUTE test USING @u;
DEALLOCATE PREPARE test;

Racunam da ako se ne izvrši DEALLOCATE onda isti statement može da se koristi vise puta do kraja izvršenja scripta.

Da li se statement automatski dealocira (brise iz memorije) kada se zavrsi script, kao sto je slucaj sa connect, da se po zavrsetku scripta automatski radi disconnect (osim ako nije permanent connect)?

O koji brzinama govorimo, da li je ovakav statement značano sporiji od običnog "SELECT email FROM users WHERE id=123" ili je čak možda i brži?

Ako želim isti statement za različite varijable da koristim nekoliko puta za redom, da li značajno oduzima vreme sama akcija PREPARE ... SET... DEALLOCATE? Hoću da kažem da li je mnogo sporije ovako:

HTML kôd:
PREPARE test FROM 'SELECT email FROM users WHERE id=?';
SET @u = 123;
EXECUTE test USING @u;
DEALLOCATE PREPARE test;

// pa se onda radi nesto drugo pa se pozove:

PREPARE test FROM 'SELECT email FROM users WHERE id=?';
SET @u = 24;
EXECUTE test USING @u;
DEALLOCATE PREPARE test;

// pa se onda radi nesto drugo pa se pozove:

PREPARE test FROM 'SELECT email FROM users WHERE id=?';
SET @u = 931;
EXECUTE test USING @u;
DEALLOCATE PREPARE test;
od ovoga

HTML kôd:
PREPARE test FROM 'SELECT email FROM users WHERE id=?';
SET @u = 123;
EXECUTE test USING @u;

// pa se onda radi nesto drugo pa se pozove:

SET @u = 24;
EXECUTE test USING @u;

// pa se onda radi nesto drugo pa se pozove:

SET @u = 931;
EXECUTE test USING @u;

DEALLOCATE PREPARE test;

cvele 12. 06. 2008. 15:40
Naravno da je brze drugo. Zasto? zato sto nema smisla koristiti prepared statement ako neces da cuvas query kesiran.
Ako si vec uradio prepare mysql je taj upit parsirao, proverio sintaksu itd Tako da sledeci put kada kazes execute on zna sta izvrsava i nebakce se tim stvarima, tako da izbegne nepotrebni overhead.

Ako konstantno radis prepare istog upita, gubi se smisao.

PS.
Pogledaj drugu temu (views) bindovi.

Za pitanje da li se automatski brise iz memorije, moj odgovor je 1001% ne :) Brise se tek kada kazes DEALLOCATE.

Moram priznati da ne znam da li bi se obrisao pri restartu mysql-a, verovatno da, mada ne mora da znaci.

Off Topic:
joj hvala ti za zadnje dve teme o db... bio sam smoren ko 37 zeceva... malo sam se unormalio dok samo ih citao :)

bluesman 12. 06. 2008. 16:02
Ok, to je jasno i očekivano, samo sam hteo da proverim.

Znači ne brišu se prepared statements nikako osim "ručno"? Što znači da bi ti mogao da ih kreiraš jednom i stalno koristiš dok god se ne restartuje mysql server? To mi i nije "očekivano" ponašanje, ali je možda "feature" :)

Kada ti kreiraš statement sa istim imenom, on naravno prepiše postojeći? Neće da generiše grešku tipa "taj statement već postoji"? Što znači da ako uvek koristiš isto ime za statement, neće sigurno da se desi da imaš alocirano 10000 statements koje ne koristiš, u najgorem slučaju taj jedan.

Mislim, sve sam ja ovo već testirao kod mene u lokalu, ali me interesuje "zvanično" ponašanje, ne znam čak ni koji mysql imam ovde i da li postoje razliku u ponašanju na "real" serveru.

DejanVesic 12. 06. 2008. 16:06
Ovo nisam koristio, pitao kolegu:

- pripremu (Prepare) je bolje raditi kroz client code nego na strani baze (ne znam zašto, ima neko objašnjenje u MySQL dokumentaciji)

- ako je već radiš na serveru: domen joj je tvoja sesija (ne vide je drugi) i konekcija (živo dok ne uradiš DEALLOCATE ili se diskonektuješ)

Naravno, ne radi DEALLOCATE sve dok ima šanse da je negde upotrebiš :)

bluesman 12. 06. 2008. 16:13
Ček, ček, ček..."živo dok ne uradiš DEALLOCATE ili se diskonektuješ" ... znači da se ipak briše kada se diskonektuješ?

DejanVesic 12. 06. 2008. 16:29
Da, provereno, ček:

Citat:
A prepared statement is specific to the connection in which it was created. If you terminate a client session without deallocating a previously prepared statement, the server deallocates it automatically.

A prepared statement is also global to the connection. If you create a prepared statement within a stored routine, it is not deallocated when the stored routine ends.
http://dev.mysql.com/doc/refman/5.1/en/sqlps.html

bluesman 12. 06. 2008. 16:37
Što znači da cvele 1001% nije u pravu :) Ili se nismo razumeli :)

Dakle, ako ne koristiš permanent konekciju, prepared statements se drop-uju čim se script automatski diskonektuje na kraju izvršenja.

ivanhoe 13. 06. 2008. 01:43
da to je to, a kod permanent konekcija ona ostaje ziva za taj apache child, tako da generalno ne mozes biti siguran da ce ti biti na raspolaganju kod sledeceg poziva skripte, jer ne znas koja apache instanca ce preuzeti request...

bluesman 13. 06. 2008. 02:43
Što znači da je sasvim safe da na početku script kreiraš statement sa istim imenom, on će da prepiše postojeći (ako postoji) i neće da ih gomila pa na kraju završiš sa istih 1000 statementa?

ivanhoe 13. 06. 2008. 08:43
apsolutno... uradis prepare, i onda samo pozivas execute posle..

cak i kad se execute poziva samo jednom, prednost prepare je sto ne moras da brines o escape-ovanju vrednosti, samo ih prosledis preko execute, a baza zna koji tip podatka treba da ocekuje... to je najsigurniji pristup protiv SQL injectiona..


Vreme je GMT +2. Trenutno vreme je 10:23.
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.