Transactions in MySQL, the default is automatically submitted that autocommit = 1;
But then, there will be problems in some cases: for example:
If you want to insert a one-time 1000 data, mysql will commit1000 times,
If we autocommit closed off [autocommit = 0], controlled by the program, as long as the first commit on it, so also in order to better reflect the characteristics of affairs!
The need for operating values, such as the amount, number and the like!
Remember one principle: a lock two sentenced to three update
In MySQL's InnoDB, the preset Tansaction isolation level is REPEATABLE READ (can be re-read)
SELECT locking in reading are two main ways:
• the IN SHARE the MODE SELECT ... LOCK
• SELECT ... the FOR UPDATE
After only performed when both ways in the transaction (Transaction) were among the SELECT to the same data table, you must wait for the other transaction data is submitted (Commit).
The main difference is that the LOCK IN SHARE MODE when one party to a transaction with a form Update likely to result in a deadlock.
Simply put, if the latter SELECT To UPDATE the same form, it is best to use SELECT ... UPDATE.
for example:
Suppose you have a number of quantity of goods stored in the form of goods products, you must first determine whether sufficient quantity quantity (quantity> 0) before the order was established, then and only then updated to the number 1. code show as below:
SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;
Why is it unsafe?
Perhaps there is no problem under the condition of a small amount, but a large number of data access "definitely" go wrong. If we need to buckle inventory in quantity> 0, assuming that the first line of the program SELECT read quantity is 2, it looks figures are not wrong, but when MySQL is preparing to UPDATE the time, some people may have inventory buckle to 0, but the program was unaware, it would be wrong of UPDATE go. Therefore, the transaction must pass through mechanism to ensure that the read and the data submitted are correct.
So we can test this in MySQL, the code is as follows:
SET AUTOCOMMIT=0; BEGIN WORK; SELECT quantity FROM products WHERE id=3 FOR UPDATE;
At this products data id = 3 data is locked (Note 3), must wait to perform other transactions after the transaction commits SELECT * FROM products WHERE id = 3 FOR UPDATE so you can ensure that quantity read in other matters numbers are correct.
UPDATE products SET quantity = '1' WHERE id=3 ; COMMIT WORK;
Submission (Commit) into the database, products unlocked.
• Note 1: BEGIN / COMMIT for the transaction start and end points, MySQL Command window to observe the interaction of two or more locking condition may be used.
• Note 2: In the transactions, only SELECT ... FOR UPDATE or LOCK IN SHARE MODE will wait until after the end of other transactions executed during the same sum of data, SELECT ... generally not affected by this influence.
• Note 3: Since InnoDB default is Row-level Lock, lock data may refer to this column.
• Note 4: InnoDB forms Do not use LOCK TABLES command, if you want to use the last resort, please see the official explanation for InnoDB uses LOCK TABLES, and avoid system deadlocks occur frequently.
MySQL SELECT ... FOR UPDATE 的Row Lock 与Table Lock
Introduced above SELECT ... FOR UPDATE usage, but the lock (Lock) data is discrimination would have to take note of. Because InnoDB default is Row-Level Lock, so only "clear" in the specified primary key, MySQL will perform Row lock (lock only the selected data), otherwise MySQL will perform Table Lock (to lock the entire data form ).
for example:
Suppose there are two forms products, there are two fields id with name, id is the primary key.
Example 1: (explicitly specify the primary key, and has the data, row lock)
SELECT * FROM products WHERE id='3' FOR UPDATE;
Example 2: (no primary key, table lock)
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
Example 3: (primary key is not clear, table lock)
SELECT * FROM products WHERE id<>'3' FOR UPDATE;
Example 4: (primary key is not clear, table lock)
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;
The optimistic and pessimistic locking strategy
Pessimistic lock: Lock a few lines, a few other updates of these lines need to continue until the end of pessimistic locking when reading data.
The optimism: do not lock when reading data, updates to check whether the data has been updated, if it is to cancel the current update, the general pessimistic lock waiting time is too long and can not accept that we will choose the optimistic lock.