O introducere în tranzacții în MySQL, vebistory
Orice tranzacție este executată fie realizată în totalitate sau deloc.
Modelul tranzacțional are două concepte fundamentale: COMMIT și ROLLBACK. COMMIT înseamnă fixarea tuturor modificărilor în tranzacție. mijloace ROLLBACK anulare (rollback) modificarea în tranzacție.
La începutul tranzacției, toate modificările ulterioare sunt stocate în depozit temporar. În cazul COMMIT, toate modificările efectuate într-o singură tranzacție să persiste în baza de date fizică. În cazul ROLLBACK va rula din nou toate modificările efectuate în cadrul tranzacției sunt eliminate.
În MySQL tranzacții sunt acceptate numai tabele InnoDB. tabele MyISAM nu suportă o tranzacție. Valoarea implicită InnoDB autocommit este activat, ceea ce înseamnă că, în mod implicit, fiecare cerere este echivalentă cu o singură tranzacție.
O tranzacție începe cu o cerere si «START TRANZACȚII» sau «ÎNCEPE». Pentru a finaliza tranzacția, trebuie să se angajeze fie modificările (COMMIT cerere), sau să le rostogolească înapoi (ROLLBACK cerere).
Exemplul COMMIT:
Exemplul ROLLBACK:
În MySQL, nu există nici un mecanism pentru tranzacții imbricate. O conexiune la baza de date - o tranzacție. O nouă tranzacție într-o singură conexiune poate începe numai după terminarea celui precedent.
Pentru unii operatori nu pot fi rulate înapoi de un ROLLBACK. Aceste declarații limbaj de definire a datelor (definiție date lingvistice - DDL). Aceasta include cereri CREATE, ALTER, DROP, TRUNCATE, COMMENT, redenumire.
Următorii operatori sunt scopuri în mod implicit o tranzacție (ca și în cazul în care COMMIT a fost emisă înainte de vypol-neniem):
- ALTER TABLE
- DROP BAZA DE DATE
- LOAD DATA MASTER
- SET AUTOCOMMIT = 1
- BEGIN
- DROP INDEX
- TABELE LOCK
- START TRANSACTION
- CREATE INDEX
- DROP TABLE
- REDENUMIȚI TABEL
- tabel trunchia
Rețineți că, în cazul unei erori SQL, tranzacția în sine nu este derulată înapoi. erorile sunt procesate de obicei deja folosind wrapper'ov sql în aplicație, cum ar fi PHP DOP instanță. Dacă doriți să reveniți schimbări în cazul în care apare o eroare direct în MySQL, puteți crea o procedură specială și să-l execute handler ROLLBACK.
Dar această metodă este destul de simplu de a revizui, și nu este un ghid de acțiune. De ce? Am foarte recomandăm să nu facă acest lucru, la fel ca în erorile principale de bază de date sunt manipulate folosind ambalaje SQL pe partea cererii, cum ar fi PHP DOP, de exemplu, de acolo pentru a gestiona pe deplin tranzacțiile.
Să considerăm un exemplu practic: există 2 tabele, utilizatori - utilizatorii și informații de utilizator - user_info. Imaginați-vă că avem 3 executați o interogare a bazei de date, sau nu le pune în aplicare deloc, deoarece în caz contrar aceasta va duce la funcționarea defectuoasă a cererii.
În general, cred că principiul de lucru al tranzacției este clar. Dar lucrurile nu sunt atât de simple. Există probleme de tranzacții concurente. Să considerăm un exemplu. Imaginați-vă că în timpul executării tranzacției, un alt utilizator a creat oa doua tranzacție paralelă și a făcut SELECT * FROM interogarea unui utilizator după tranzacția noastră a fost executat prima solicitare «INSERT INTO utilizator (id, NIK) VALORI (1,«nikola») “. Ceea ce utilizatorul vede a doua tranzacție? Va fi el putea vedea postul inserat, chiar și atunci când rezultatele primei tranzacții nu a fost încă comis (nu a avut loc COMMIT)? Sau poate vedea modificările numai după rezultatele primei tranzacții vor fi înregistrate? Intoarceri au loc ambele. Totul depinde de nivelul de izolare de tranzacție.
Avem nivel de izolare 4 tranzacție:
- 0 - Citirea datelor (neconfirmat murdare citește) (Read neangajată, murdar Read) - cel mai scăzut nivel de izolare. Atunci când acest nivel este posibil pentru a citi modificările neangajate în tranzacțiile concurente. Doar în acest caz, al doilea utilizator vede înregistrarea introdus din prima tranzacție nealiniate. Nu există nici o garanție că tranzacția neangajate va fi derulată înapoi în orice moment, astfel încât această lectură este o sursă potențială de eroare.
- 1 - Citirea datelor verificate (Read Angajate) - aici este posibil să se citească date numai tranzacțiile angajate. Dar, la acest nivel există două probleme. În acest prompt, care participa la selecție în cadrul unei tranzacții, alte tranzacții concurente nu sunt blocate, acest lucru implică un număr de problemă 1: „lectură» Onetime (citire non-repetabile) - este o situație în care o tranzacție are loc mai multe probe (SELECT ) în conformitate cu aceleași criterii și printre aceste probe se efectuează într-o tranzacție paralelă, care modifică datele implicate în aceste probe. Deoarece datele de tranzacție concurente sa schimbat, rezultatul următorului eșantion de aceleași criterii ca și în prima tranzacție, nu va fi o alta. Problema numărul 2 - „fantomă citește“ - acest caz este discutat mai jos.
- 2 - repetabile citit (Citire repetabilă, Instantaneu) - este de asemenea posibil să se citească date numai tranzacțiile angajate la acest nivel de izolare. De asemenea, la acest nivel nu există nici o problemă de „citire non-repetabile“, adică liniile care sunt implicate în selectarea în cadrul unei tranzacții sunt blocate și nu pot fi modificate de alte tranzacții concurente. Dar masa nu este complet blocat. Din acest motiv, există o problemă „fantomă citit.“ „Phantom citit“ - este atunci când peste poate varia din cauza faptului că nu întregul tabel este blocat, iar numai rândurile care sunt implicate în eșantion la momentul execuției unei tranzacții rezultatul acelorași probe. Acest lucru înseamnă că tranzacțiile paralele pot insera rânduri în tabel, în care se efectuează prelevarea de probe, astfel încât cele două interogare SELECT * FROM tabel poate da rezultate diferite în momente diferite, atunci când introducerea de date concurenta.
- 3 - Serializable (Serializable) - tranzacții serializabile. Cea mai sigura Nivelul de izolare tranzacție, dar, de asemenea, în același timp, este cel mai lent. La acest nivel, în absența oricărei probleme de tranzacții simultane, dar va trebui să plătească performanța sistemului și performanța, în cele mai multe cazuri, este esențial.
În mod implicit, MySQL este numărul de nivel de izolație 2 instalat (Citire repetabilă). Și, după cum cred eu, dezvoltatorii MySQL au făcut nu este în zadar implicit acest nivel, deoarece acesta este cel mai de succes, în cele mai multe cazuri. Din prima dată poate părea ca cel mai bun număr opțiunea 3 - este cel mai de încredere, dar, în practică, puteți experimenta un inconvenient major datorită performanței foarte lentă a cererii dumneavoastră. Amintiți-vă că de mult nu depinde de cât de bine nivelul de izolare de tranzacție într-o bază de date, precum și cu privire la modul de a proiecta cererea dumneavoastră. Cu programarea corespunzătoare, puteți utiliza chiar și cel mai scăzut nivel de izolare tranzacție - totul depinde de caracteristicile dezvoltării structurii și alfabetizarea cererii dumneavoastră. Dar este inutil să caute cel mai scăzut nivel de izolare - nu doar dacă utilizați nu este modul cel mai sigur, trebuie amintit despre problemele de tranzacții simultane, caz în care nu obține confuz și a făcut totul corect.
SET TRANSACTION - această declarație stabilește nivelul de izolare a tranzacției următoare, la nivel global, sau numai pentru sesiunea curentă.
conexiunile existente nu sunt afectate. Pentru a realiza acest lucru, operatorul trebuie să aibă privilegiul SUPER. Utilizarea SESIUNE gura-navlivaet nivelul de izolare implicit cuvânt cheie pentru toate tranzacțiile viitoare numai pentru CURRENT-prezent o sesiune.
Puteți seta, de asemenea, nivelul inițial de izolare la nivel mondial pentru serverul mysqld rulând cu opțiunea -transaction-izolare