mysql drop锁表 mysql 锁表处理

MySQL大致可归纳为以下3种锁：

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。(比如 A 对数据库user表ID1-5的数据加锁  请求 6-9数据  B 对数据库user表 6-9 数据加锁 同时读取 1-5数据 此时 A等待B  B等待A  出现死锁)
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

show OPEN TABLES where In_use > 0;//查询mysql 哪些表正在被锁状态

查看锁线程:

 show processlist;//显示所有mysql线程

SELECT * FROM information_schema.INNODB_TRX；//查看锁线程
kill thread_id;//杀死线程

 

MySQL中select * for update锁表的问题（必须开启事务 只支持innodb）

由于InnoDB预设是Row-Level Lock，所以只有「明确」的指定主键，MySQL才会执行Row lock (只锁住被选取的资料例) ，否则MySQL将会执行Table

Lock (将整个资料表单给锁住)。 举个例子: 假设有个表单products ，里面有id跟name二个栏位，id是主键。

例1: (明确指定主键，并且有此笔资料，row lock)

SELECT * FROM products WHERE id='3' FOR UPDATE;
SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

例2: (明确指定主键，若查无此笔资料，无lock)

SELECT * FROM products WHERE id='-1' FOR UPDATE;

例2: (无主键，table lock)

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

例3: (主键不明确，table lock)

SELECT * FROM products WHERE id<>'3' FOR UPDATE;

例4: (主键不明确，table lock)

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

注1: FOR UPDATE仅适用于InnoDB，且必须在交易区块(BEGIN/COMMIT)中才能生效。

注2: 要测试锁定的状况，可以利用MySQL的Command Mode ，开二个视窗来做测试。
在MySql 5.0中测试确实是这样的

另外：MyAsim 只支持表级锁，InnerDB支持行级锁 添加了(行级锁/表级锁)锁的数据不能被其它事务再锁定，也不被其它事务修改

（修改、删除） 。是表级锁时，不管是否查询到记录，都会锁定表。

如何测试

在 MySQL 命令行终端操作一个表

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from users for update;
+----+------+
| id | name |
+----+------+
|  1 | tom  |
|  2 | bob  |
+----+------+

这时再开一个命令行终端

mysql> select * from users for update;
^C^C -- query aborted
ERROR 1317 (70100): Query execution was interrupted
mysql> select * from users lock in share mode;
^C^C -- query aborted
ERROR 1317 (70100): Query execution was interrupted

你会发现，无论是 for update 还是 lock in share mode 都无法读取到数据，更加确切地说是，查询被阻塞了。

只有在第一个终端执行

commit;

需要注意的是，发起者必须在 transaction 里上锁才有效，如果不是在 transaction 中，上锁是无效的。但是，第二个人无论是不是在 transaction 里，都会被锁。

表级锁

LOCK TABLES `user` READ|WRITE;锁表
UNLOCK TABLES;//解锁

 

悲观锁 和 乐观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

 

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

 

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

for update 和 LOCK IN SHARE MODE

• sharedLock 对应的是 LOCK IN SHARE MODE
• lockForUpdate 对应的是 FOR UPDATE

sharedLock 与 lockForUpdate 相同的地方是，都能避免同一行数据被其他 transaction 进行 update。

不同的地方是：

• sharedLock 不会阻止其他 transaction 读取同一行
• lockForUpdate 会阻止其他 transaction 读取同一行 （需要特别注意的是，普通的非锁定读取读取依然可以读取到该行，只有 sharedLock 和 lockForUpdate 的读取会被阻止。）

即 sharedLock locks only for write, lockForUpdate also prevents them from being selected

这样做是有意义的，例如，两个 transaction 要更新同一个计数器，如果不使用 lockForUpdate， 会导致两个 transaction 同时读到同一个初始值，然后在应用层逻辑中增加计数之后，提交到数据库中，后者的操作会覆盖掉前者的操作