MyISAM storage engine: small overhead, locked fast, no deadlock. Locking granularity, low degree of concurrency, prone to locking conflicts. It does not support transactions. Using the table lock (locking operation on the operation table) substantially without the
innoDB storage engine: large overhead, deadlocks, lock small size, not prone to conflict. Using the line lock (lock operation when the end of each row sql execution), but also supports table locks mysql default engine
Question: oversold stocks
Stock 1, the results of two people later, after the first person is determined as well as a surplus, then execute the update operation, the start time of the second individual determination, when update is not over, the remaining or 1, then started into the update operation, resulting in inventory becomes -1.
1. pessimistic locking, join the select statement in judge row locks, and update statements are mutually exclusive, the first personal guarantee before committing the transaction, the second person can not operate this cargo.
2. Optimistic locking, you add a version field, an updated version of the query field, a version field changes can not be updated.
select num, version from warehouse where id = Product Number; number of queries simultaneously detect versions, such as 111
update warehouse set num = num - 1, version = version + 1 where version = 111; warhouse if such product is changed in this inquiry, this will not change any of the fields. If successful, the release also changed to 112.
reference： http://www.zsythink.net/archives/1233/
Transaction Isolation:
Uncommitted Read: read-uncommitted Possible problems: dirty reads, phantom read, read A non-repeatable not submitted after the modify operation, B can see changes
Read Committed: read-commited Possible problems: phantom read, non-repeatable read modify operation submitted after the A, B can see changes
Repeatable Read: repeatable-read Possible problems: A modified after the read operation can not be repeated after the operation B is also used to see the same table can be altered to A
Serializable: serialiazable three of these modified operation does not occur when A, B can not do even read. In this way the most secure, but not concurrent, efficiency is too low.
Dirty read: read uncommitted changes to someone else (the actual data table does not change, but do you think has changed) B modifies the data have not submitted, A found in the data submitted failed to roll back the B, A B that change over .
Phantom read: not (change the number of data tables) A number after the inquiry, B is added or deleted data, A that the data has not changed.
Non-repeatable read: read and modify inconsistent state (the data value is changed) after querying A, B modifies the data value, A is the old data as the judgment condition.
Non-repeatable read and phantom read about the same, but one is somehow more than a line, a value is somehow changed. So oversold stocks is not repeatable read.
1.
Query the database transaction isolation levels:
VARIABLES SHOW the LIKE ' % Isolation ' ; # check the Internet version tx_isolation, my version is transaction_isolation, so the direct use of fuzzy query
Usually Repeatable Read
2. Modify the isolation level:
SET transaction_isolation = 'read-uncommitted';
mysql locks: Table name index_test
1. View the table storage engine
SHOW TABLE STATUS LIKE 'index_test';
2. Modify the table storage engine
The ALTER TABLE index_test ENGINE = MYISAM; # engine modification table SHOW TABLE STATUS LIKE 'index_test';
Table 3. Lock
Table lock locks have read, and write locks
Read locks: do not let other connections to modify the table, you can query!
Write locks: do not let others join query and modify the table.
- - ||| careful not just by the literal meaning of understanding, sometimes resulting in read lock is easy not to read, write, write lock is to keep the illusion (like me ...)
1). Add to index_test write lock table (in this case the current session database connection table is modified.)
LOCK TABLE index_test WRITE;
2) Create a new database connection (File -> New links are not open a new query editor window = = sqlyog or open a new window or the same link with ...)
Then modify index_test table (query result is the same)
I can see will always display processing.
3) At this time unlocking the first connection table
UNLOCK TABLES;
Found the second connection modification statements immediately executed.
Individual test (I have a bold idea):
Establishing a connection a, b, c
a lock table
b modified - into the waiting
c enter the unlock
b still waiting
c lock table - waiting to enter
Unlock a - b is finished, c finished
a lock table - into the waiting. . . Because the table lock c
c Unlock
It can be concluded: table lock and unlock different connections are independent. . .
4) For a read lock table index_test added (this time in the current session database connection table is modified.)
LOCK TABLE index_test READ;
At this second connection, it will enter the wait state changes, but you can query.
4. Line lock
myisam only table-level locking, so to switch back to innodb
Row lock: When the statement is executed only lock the relevant data rows, instead of the entire table. This is also one of the main support innodb transactions. (If the lock table, when used in a transaction more than one table, the database will lead to many tables are locked, significantly slow down the efficiency)
innodb will automatically modify the statement to add a row lock.
Table 1. Change engine
ALTER TABLE index_test ENGINE = INNODB;
2. canceled automatically submitted (innodb will separate sql statement as a transaction submitted directly, after cancellations must commit to committing a transaction)
SET autocommit = 0;
3. Make an edit
UPDATE index_test SET key1 = 1 WHERE t_id = 1;
New connection 2, modifications to the table
UPDATE index_test SET key1 = 3 WHERE t_id = 1;
2 entered connection wait
After some time prompt timeout
1 is connected to commit changes
COMMIT;
2 attempt to modify the connection again, success
Individual test: Since it is a row lock, try to see the results in the data line connecting two different modifications - -
Connection 1:
UPDATE index_test SET key1 = 1 WHERE t_id = 1;
Connection 2:
UPDATE index_test SET key1 = 3 WHERE t_id = 2;
2 is connected directly modify successfully.
5. To add a row lock query
Stock oversold pessimistic locking to solve the problem:
Pessimistic locks, row locks to join the select statement in the judgment, the first personal guarantee before committing the transaction, the second person can not operate this cargo.
Examples of the table with index_test
t_id = 1 this line, key = 1. Key1 assumed a cargo, the remaining 1
a query, but locks up, ready to update
SELECT * FROM index_test WHERE t_id = 1 FOR UPDATE;
b then began to query
SELECT * FROM index_test WHERE t_id = 1 FOR UPDATE;
Generating read exclusive, b into the waiting, to wait for a commit.
update and submit a
UPDATE index_test SET key1 = key1 - 1 WHERE t_id = 1; COMMIT;
After submitting a, b find out the results
key1 has become 0
Thus avoiding stocks oversold.
Deadlock:
And almost java. . .
a: Query A, lock A, found Once modified B, and then submit
b: query B, locking B, and so found after modifying A, then submit
For a, B needs to be modified in order to commit the transaction, then unlock A.
For b, A need to change in order to submit the transaction, then unlock B.
Forming a deadlock.
Occupied key to each other.
Solve: kill off one of the threads. (Such as a graphical interface directly sqlyog a point x to get away ... but linux development sometimes use the name of the command-line kind of - -)