I need to use a transaction in my project on MySQL. But I'm not sure if I have to use mysql_query("SET AUTOCOMMIT=0"); or not.
I know I have 2 options:
BEGIN
START TRANSACTION
Also I have heard that one of the both items does not need using AUTOCOMMIT = 0.
Please help me to know when I have to use AUTOCOMMIT = 0 actually, With BEGIN or with START TRANSACTION?
Thank you.
As explained in the manual:
By default, MySQL runs with autocommit mode enabled. This means that as soon as you execute a statement that updates (modifies) a table, MySQL stores the update on disk to make it permanent. The change cannot be rolled back.
To disable autocommit mode implicitly for a single series of statements, use the START TRANSACTION statement:
START TRANSACTION;
SELECT #A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=#A WHERE type=1;
COMMIT;
With START TRANSACTION, autocommit remains disabled until you end the transaction with COMMIT or ROLLBACK. The autocommit mode then reverts to its previous state.
The manual goes on to say:
To disable autocommit mode explicitly, use the following statement:
SET autocommit=0;
After disabling autocommit mode by setting the autocommit variable to zero, changes to transaction-safe tables (such as those for InnoDB or NDBCLUSTER) are not made permanent immediately. You must use COMMIT to store your changes to disk or ROLLBACK to ignore the changes.
autocommit is a session variable and must be set for each session. To disable autocommit mode for each new connection, see the description of the autocommit system variable at Section 5.1.3, “Server System Variables”.
BEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for initiating a transaction. START TRANSACTION is standard SQL syntax and is the recommended way to start an ad-hoc transaction.
There is a small difference between Start Transaction and SET AUTOCOMMIT=0.
If START TRANSACTION appears at the beginning of session and AUTOCOMMIT is set 1 (Mysql begins with AUTOCOMMIT enabled) after ROLLBACK, Autocommit is set silently to 1 again
If I put SET AUTOCOMMIT=0, instead of START TRANSACTION, evidently a ROLLBACK let AUTOCOMMIT disabled
Related
SET autocommit = 0;
start transaction;
update ... where ID=29;
rollback;
Whether autocommit is 1 or 0 does not seem to affect the rollback? Does autocommit ontrol whether update is committed immediately or not? What does autocommit supposed to affect?
Even if you have autocommit enabled, that doesn't stop you from starting a transaction. When you explicitly start a transaction, this supercedes autocommit for the duration of the transaction. Once you commit (or rollback), autocommit resumes at its previous value.
So if you explicitly start a transaction, you can rollback, even if normally you have autocommit enabled.
From documentation autocommit, Commit, and Rollback:
If autocommit mode is enabled, each SQL statement forms a single transaction on its own
It means that after DML statement ends(without error), it is committed(unless it is wrapped with explicit transaction).
So this is from the docs:
To disable autocommit mode implicitly for a single series of
statements, use the START TRANSACTION statement:
START TRANSACTION;
SELECT #A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=#A WHERE type=1;
COMMIT;
So from my understanding, unlike using BEGIN; command which shouldn't set autocommit to 0, START TRANSACTION should set it to 0.
Now if I do this (after I start a transaction):
select ##autocommit;
I get the value of 1.
Why autocommit is still enabled even if I use START TRANSACTION command? I thought that the autocommit variable is local to a single session. Or maybe even if it says 1, it is actually set to 0 within a transaction but just can't get that info by running a SELECT ##autocommit; query?
https://dev.mysql.com/doc/refman/5.7/en/commit.html says:
With START TRANSACTION, autocommit remains disabled until you end the transaction with COMMIT or ROLLBACK. The autocommit mode then reverts to its previous state.
The value of the autocommit variable is where MySQL stores the "previous state" so that it can revert to it after your transaction completes.
You can experimentally confirm that this behavior is followed. Make a change in a transaction, and then roll back the transaction.
CREATE TABLE test.MyTable (mycolumn TEXT);
START TRANSACTION;
INSERT INTO test.MyTable (mycolumn) VALUES ('Thing 1');
ROLLBACK;
SELECT * FROM test.MyTable; -- finds the row is gone
Notice that the change you did is rolled back. If autocommit had been in effect, then rollback would never work, because each statement would commit as soon as it is executed.
I suggest that ##autocommit is irrelevant. The engine knows that it is in a transaction (START or BEGIN), so it ignores the setting of autocommit. Instead it hangs onto changes until COMMIT (or ROLLBACK).
Or do you have some reason to believe that the value of autocommit is relevant? (Aside from SELECT ##autocommit.)
To my knowledge for InnoDB tables in MySQL, all transactions are wrapped with a START TRANSACTION; and end with a COMMIT; unless explicitly stated not to.
If I were to explictly define the transaction block, would it be correct to do something like this:
SET AUTOCOMMIT = 0;
START TRANSACTION;
[SQL STATEMENTS]
COMMIT;
SET AUTOCOMMIT = 1;
Would the next transaction after this go back to the way InnoDb handles transactions by default? My intention is to only sometimes have explicitly defined transactions in my application but all other transactions will be handled by the engine.
You do not need to set autocommit to 0 in your case. Defining a transaction implicitly does that for you. From MySQL documentation:
"To disable autocommit mode implicitly for a single series of statements, use the START TRANSACTION statement:"
It seems like you can achieve all you need with transactions using only BEGIN; ROLLBACK and COMMIT;. Are there certain scenarios that require using autocommit? Does calling BEGIN; set autocommit to false? Does calling COMMIT; set autocommit to true?
autocommit can be set per session or globally. No scenario that require autocommit (not all RDMS support auto-commit mode). In my opinion, the reason why autocommit is presented and true by default is because MyISAM engine does not support transactions at all, so to alleviate porting applications written for MyISAM they mimic the same behaviour.
Does calling BEGIN; set autocommit to false? Does calling COMMIT; set autocommit to true?
From mysql documentation
To disable autocommit mode for a single series of statements, use the START TRANSACTION statement: ...
With START TRANSACTION, autocommit remains disabled until you end the transaction with COMMIT or ROLLBACK. The autocommit mode then reverts to its previous state.
I have a user table, and I have 5 records.
I deleted two records, then executed the rollback command, it executed successfully.
But that deleted two records not recovered.
The user table engine is InnoDB.
You should be able to rollback your transaction as the table engine is InnoDB.
Anyways here is the correct way to do transactions,
SET autocommit=0;
START TRANSACTION;
Your Query here.
ROLLBACK;
and make sure that you are not using COMMIT after the Query which you need to rollback. Refer
Table Engines and Transaction. And When a DB connection is created, it is in auto-commit mode by default. This means that each individual SQL statement is treated as a transaction and is automatically committed right after it is executed. So if you need to do transactions yourself, you must turn off the autocommit mode by AUTOCOMMIT = 0. Refer this link for more info.
By default, MySQL starts the session
for each new connection with
autocommit enabled,
You could set autocommit mode disable before running your query
SET autocommit=0;
ref:
Link 1
Link 2
Make sure you already do command
start transaction;
before the query delete.
SET autocommit=0;
BEGIN;
.
.
.
ROLLBACK;
START TRANSACTION, COMMIT, and ROLLBACK Syntax
I don't know if you were locking tables, but I ran into the same problem where it seemed like rollback wasn't working.
Within my transaction I called "LOCK TABLES...", which
implicitly commits any active transaction before attempting to lock
the tables
(http://dev.mysql.com/doc/refman/5.0/en/lock-tables-and-transactions.html)
I ended up locking outside of (before) the transaction, as that was the first thing I was doing in the transaction anyway. Alternatively, you can do as the docs suggest:
SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
... do something with tables t1 and t2 here ...
COMMIT;
UNLOCK TABLES;
I have the same problem, but i has checked the innodb support
First:
Verify if the Engine INNODB is Available: with this:
mysql> show engines;
if INNODB is disabled: then
Second:
go to the file "my.ini", in my case is in C:\AppServ\mysql
in this file removes the "#" of the line
#default-storage-engine=INNODB -> default-storage-engine=INNODB
and the line skip-innodb add "#"
skip-innodb -> #skip-innodb
Third:
save and restart mysql service, and the problem was solved.
I think there is one important thing to mention: to re-enable autocommit after transaction is done.
SET autocommit = 0;
START TRANSACTION;
INSERT INTO ..
UPDATE <table> ..
COMMIT;
SET autocommit = 1;
Otherwise anything you do after disabling autocommit even without transaction will require you to explicitly commit.
If you're using MySQL Workbench you can turn off Auto-commit transactions in 'Query' tab.
And don't forget to use "COMMIT;" after the Query which you need to rollback.
Even for me rollback was not working for InnoDB engine.
But adding begin; statement after start transaction; made the fix.
This worked for me
SET autocommit = 0;
start transaction;
begin;
-- DML query goes here
rollback;
SET autocommit = 1;
But
This doesn't worked for me
SET autocommit = 0;
start transaction;
-- DML query goes here
rollback;
SET autocommit = 1;
Really i don't know the reason, If anyone knows please comment here.