MySQL locks
I say 锁we certainly no stranger to lock Well, for concurrent operation, the security of the data.
Java also has a lock, synchronizedandLock
Operating system also has a lock as long as it is related to multi-threaded certainly can not do without lock.
MySQL is the same, but different issues addressed, the type of lock is somewhat different, mainly related to size.
(Based on the InnoDB engine)
MySQL lock Category
MySQL locks, divided into three categories
- Overall situation
- Table level
- Row-level
Particle size from coarse to fine.
Global Lock
Global Lock, by definition is locked to the database. In this case, the database can not operate, can only wait for the operation to complete.
This operation is generally used 全库逻辑备份. Makes an entire library 只读. This operation is very scary to think ah.
That whole business may not want to shut down all of it?
Why it got to be locked?
Lock, for when the backup database, data can be affected.
Imagine, in the bank transfer business. If the backup is not locked, suddenly appeared abnormal. Account balance is not deducted,
it was not all over!
Table-level locking
Table lock
Table lock, because row locks, now rarely used. Modifying effect on the entire table.
Will lock the entire table, other operations can not be performed. Consideration large.
For example, if performing lock tables t1 read in the thread A, Write t2; this statement,
the thread A can only read t1, t2 write write only while other threads t1, read t2..
Metadata (Metadata) lock
Metadata lock with the structure of the table. 读写锁.
-Write lock may be simultaneously read, but not written simultaneously. Read exclusive.
When you change the structure of the table, be sure to get 写锁in. Otherwise you this change it, change it's him. That failure mess it!
In addition, in fact, at the time of the query you will get the default metadata lock. Get读锁
Think about it, if the query data when the investigation is over. Discovered and existing fields not on the. Then how can do it!
session1 , session2,都是读取数据.它们可以获得读锁,进行查询.
但是当session3 要去添加字段的时候,它要获得写锁,它被阻塞了.
那么session4 来的时候,得不到读锁.它就会一直等待.可能会导致数据库崩了.
行级锁
行锁
行锁,就是一个非常常见的锁了.行级锁在进行数据的更改操作时,
肯定会先得到这一行的锁,然后再进行数据的更新.
当两个更新操作同时更改同一行数据时,就必须等一方commit后,另一方才能继续进行操作.
在InnoDB中行锁是在需要的时候才加上的,在commit之后才归还的.
两阶段锁
那么会涉及到一个两阶段锁的问题.
在事务A执行时,它update了id为1的行,那么事务B,就必须等待事务A提交才能进行下去.
锁是肯定会影响数据的并发的.那么,我们可以调整sql语句的顺序.尽量把更新操作向后推.
减少事务间的锁等待.提高并发!
有一个问题:如果删除 10000 行数据,下面三种情况哪种更合适
- 在一个连接中一次删除 10000行
- 在一个连接中循环10次删除 10000行
- 在10 个连接中共删除 10000行
聪明的你,一定知道是第二种最好了吧!
因为这样可以减少其它线程等待的时间.
死锁
如果上面的图片中事务A和事务B分别有对方想要更新的行,那么就会造成死锁.
在图中,当事务A更新了id为1的行后,事务B更新了id为2的行.
但是,这两个事务都没有commit.这就意味它们都留着锁呢!
Next, when you want to update the id of the transaction A lock 2, but then, as the lock id 2 B where it matters.
It is not, then it can only wait.
Transaction B is similar. It can not get id of lock 1. Thus two transactions will wait for each other. Do not release the lock each other!
That good. This has been waiting to go on. Is formed 死锁
Of course, the database will try to help us resolve the deadlock.
- Timeout detection, the default is considered to be a deadlock over 50s;
- Deadlock detection, to proactively detect whether there is a dependency presence, active roll back the transaction.
