1, MYSQL common types of locks:
MySQL There are three levels of locks: page-level, table level, row level.
MyISAM and MEMORY storage engine uses a table-level lock (table-level locking);
BDB storage engine uses a lock page (page-level locking), but also supports table-level locking;
InnoDB storage engine supports both row-level locking (row-level locking), also supports table-level locking, but the default is to use row-level locking.
MySQL lock these three characteristics may be roughly summarized as follows:
Table-level lock: Small overhead, lock fast; not deadlock; lock large size, the probability of lock conflicts of the highest and lowest degree of concurrency.
Row-level locking: large overhead, locking slow; there will be a deadlock; locking the smallest size, lowest probability of lock conflicts, have the highest degree of concurrency.
Page lock: locking overhead and time boundaries between the table and row locks; there will be a deadlock; locking granularity boundary between the table and row locks, concurrency in general.
2. will result in a deadlock under what circumstances
Deadlock refers to two or more transactions occupy each other on the same resources, and requests the vicious circle phenomenon locking, it caused. When multiple transactions try to lock the same resource in a different order, it will produce a deadlock. Any time multiple transactions at the same time locking the same resource, certain deadlock.
For example, consider the following two transactions processed simultaneously test table:
表结构如下：
CREATE TABLE `test` (
`id` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
Insert data:
insert into `test` ( `id`, `name`) values ( '1', '1111')
insert into `test` ( `id`, `name`) values ( '2', '2222')
(1) Open the first command line
The answer to the first set does not automatically commit the transaction:
set autocommit=0;
Check whether to close automatically submit:
show VARIABLES like 'auto%';
Query locking (pessimistic locking):
the SELECT * from the Test Update for the WHERE the above mentioned id = 1;
(2) Open the second command line:
The answer to the first set does not automatically commit the transaction:
set autocommit=0；
Check whether to close automatically submit:
show VARIABLES like 'auto%'
Query locking (pessimistic locking):
the SELECT * from the above mentioned id = 2 for the Test the WHERE Update;
(3) window will always turn, waiting for the end of the first transaction
The final tips:
(4) show processlist answer used in the first
You can see the second lock when first agreed to wait for the lock release.
(5) other places to go will be prompted to modify the data
(6) in the background process you will see a lot of processes in a wait state