Въведение в сделки в MySQL, vebistory

Транзакция - операция, състояща се от един или повече заявки към базата данни. Същността на сделката - за да се гарантира правилното изпълнение на всички искания в една сделка, както и като механизъм за осигуряване на изолация на сделките помежду си за решаване на споделяне на данни.

Всяка сделка е било изпълнено изцяло или не извършва най-малко.

В транзакционен модел има две основни понятия: COMMIT и ROLLBACK. COMMIT е записът всички промени в сделката. средства ROLLBACK анулиране (намаление на цените) промените в сделката.

В началото на сделката, всички последващи промени се съхраняват на временен склад. В случай на извършване, всички промени, направени в една сделка, за да продължават да съществуват във физическия базата данни. В случай на ROLLBACK ще се връщам всички промени, направени в рамките на сделката, се изхвърля.

В MySQL сделки се поддържат само маси InnoDB. MyISAM таблици не подкрепят сделка. По подразбиране InnoDB на autocommit е активирана, което означава, че по подразбиране, всяка заявка се равнява на една сделка.

A транзакция започва със специална молба «СТАРТ СДЕЛКИ» или «ЗАПОЧНЕТЕ». За завършване на сделката, трябва или да извърши промените (COMMIT заявка), или да ги отмени промените (искане ROLLBACK).

Пример COMMIT:

Пример ROLLBACK:

В MySQL, няма механизъм за вложени транзакции. Една връзка с базата данни - една транзакция. Нова сделка в рамките на една връзка може да започне само след завършване на предишната.

За някои оператори не може да се навива обратно чрез намаление на цените. Този език изявления разделителна способност на данни (Data Definition Language - DDL). Това включва искания създава, променя, DROP, TRUNCATE, коментар, преименувате.

Следните оператори са имплицитно завършва сделка (като че ли COMMIT е бил издаден преди vypol-neniem):

ALTER TABLE
DROP DATABASE
LOAD DATA MASTER
SET AUTOCOMMIT = 1
ЗАПОЧНЕТЕ
DROP INDEX
LOCK ТАБЛИЦИ
START СДЕЛКИ
CREATE INDEX
DROP TABLE
ПРЕИМЕНУВАНЕ TABLE
TRUNCATE TABLE

Имайте предвид, че в случай на грешка SQL, самата операция не се навива обратно. грешки обикновено се обработват вече използвате SQL wrapper'ov в заявлението, като PHP ЗНП инстанция. Ако искате да отмените промените, ако възникне грешка директно в MySQL, можете да създадете специална процедура и трябва да го изпълни ROLLBACK манипулатор.

Но този метод е доста проста, за да направи преглед и да не е ръководство за действие. Защо? Аз силно препоръчвам да не го прави, както и в основните грешки в базата данни се обработват с помощта на SQL обвивки на страната на заявлението, като например PHP ЗНП например, от там да се управлява изцяло на сделките.

Помислете за един практически пример: има 2 маси, потребители - потребители и информация за потребителя - user_info. Представете си, че имаме 3 Изготвяне на заявка база данни или не ги прилагат на всички, защото в противен случай това ще доведе до повреда на заявлението.

Като цяло, мисля, че принципът на работа на сделката е ясна. Но нещата не са толкова прости. Има проблеми с едновременни операции. Помислете за пример. Представете си, че по време на изпълнение на сделката, друг потребител е създал втора паралелна операция и не SELECT * FROM на заявката на потребителя, след като ни сделка е била изпълнена първата заявка «вмъкнете в потребител (ID Ник) стойности (1," Никола ") ". Това, което потребителят вижда втората сделка? Дали ще бъде в състояние да видите поставена пост, дори и когато резултатите от първата сделка все още не е извършил (не настъпили комит)? Или той може да видите промените само след резултатите от първата сделка ще бъдат записани? Включва се провеждат едновременно. Всичко зависи от нивото на изолация на транзакция.

В момента има 4-то ниво транзакция изолация:

0 - Четене на непризнати данни (мръсна прочитания) (Прочетена Uncommitted, Dirty Read) - най-ниското ниво на изолация. Когато това ниво е възможно да се чете не са поети промени в едновременни операции. Само в този случай, вторият потребител вижда поставен рекорд от първия неангажирани сделката. Няма гаранция, че са усвоени сделката ще се завъртя обратно по всяко време, така че това четене е потенциален източник на грешка.
1 - четене проверени данни (Прочетена Ангажиран) - тук е възможно да се чете само на извършените транзакции данни. Но на това ниво има два проблема. В този ред, който участва в подбора в рамките на сделка, други едновременни операции не са блокирани, това означава проблем номер 1: "Onetime четене» (без повторно четене) - това е ситуация, когато е извършена операцията, няколко проби (SELECT ) в съответствие с едни и същи критерии и сред тези проби се извършва паралелно сделка, която променя данните, които участват в тези проби. Тъй като едновременното данни сделка се е променило, в резултат на следващата проба на същите критерии, както и в първия сделката, няма да има друг. Проблем номер 2 - "фантом чете" - този случай се обсъжда по-долу.
2 - при повторно четене (при повторно четене, Snapshot) - също така е възможно да се чете данни само ангажираните сделки на това ниво на изолация. Също така на това ниво няма проблем с "да бъде повторено, четене", т.е. линии, които са ангажирани в избора в рамките на сделка, са блокирани и не могат да бъдат променяни от други едновременни операции. Но на масата не е напълно блокирано. Поради това, че има проблем "фантом чете." "Фантомът чете" - е, когато над може да варира, поради факта, че не цялата таблица е заключена, а само редовете, които са включени в извадката, по време на изпълнение на сделка в резултат на същите проби. Това означава, че паралелни транзакции могат да вмъкват редове в таблицата, в която се извършва вземане на проби, така че два заявката SELECT * FROM маса може да даде различни резултати по различно време, когато поставяте едновременност данни.
3 - Serializable (Serializable) - Serializable сделки. Най-сигурният ниво изолация сделка, но и в същото време е най-бавно. На това ниво, при липсата на каквито и да било проблеми едновременни операции, но това ще трябва да плати на производителността на системата, както и изпълнението, в повечето случаи е от съществено значение.

По подразбиране, MySQL е инсталиран ниво изолация номер 2 (при повторно четене). И тъй като аз вярвам, MySQL разработчици са направили не е напразно подразбиране това ниво, тъй като тя е най-голям успех в повечето случаи. От първия момент на това може да изглежда като най-добрият вариант номер 3 - това е най-надеждни, но на практика можете да се наслаждавате голямо неудобство поради много бавно изпълнение на вашата кандидатура. Не забравяйте, че много не зависи от това колко добре на ниво транзакция изолация в база данни, както и за това как да проектирате вашата кандидатура. С подходящо програмиране, можете дори да използвате най-ниското ниво на изолация сделка - всичко зависи от характеристиките на структурата и грамотност развитието на вашата кандидатура за. Но е необходимо да се търси най-ниското ниво на изолация - не само, ако използвате не е най-сигурният начин, трябва да се помни за проблемите на едновременни операции, като в този случай не се объркате и направиха всичко по силите си.

SET сделката - това изявление определя нивото на изолация на следващата сделка, в световен мащаб, или само за текущата сесия.

Съществуващите връзки не са засегнати. За да постигне това, операторът трябва да имат привилегията SUPER. Използването на СЕСИЯ уста navlivaet нивото на изолация, ключовите думи по подразбиране за всички бъдещи сделки само за текущата-присъства на сесията.

Можете също да зададете начална глобалното ниво на изолация за Mysqld сървъра, като го извикате с опция -transaction-изолация