Mariadb之显式使用表锁和行级锁

　　首先我们来看看mariadb的锁定概念，所谓锁就是当一个进程或事务在操作某一资源时，为了防止其他用户或者进程或事务对其进行资源操作，导致资源抢占而发生冲突，通常在A进程操作该资源时，会对该资源进行加锁，实现多进程或多用户操作同一资源时，不会发生冲突；通常情况锁的类型分读锁和写锁，所谓读锁就是共享锁，它可以实现多个读操作共享；而写锁就是排它锁，独占锁，一旦加了写锁，其他用户的读写操作将被阻塞，直到该写锁被释放或者因超时而被释放，在其他用户进行的读写操作，此时就会被执行；对于锁定范围来讲，它又可以分为，表锁和行锁，从字面意思就可以理解到，表锁就是针对整张表所施加的锁，而这种锁定力度相当粗糙，并发相对就比较低，但是维持锁状态锁消耗的成本资源就较小；对于行锁来说，它针对的范围就是行级别所施加的锁，这种锁的粒度就相对要精细，同时并发相对较高，但是维护锁状态消耗的成本资源就相对要大；对于mysql来讲又分为存储引擎的锁和mysql server的锁，存储引擎的锁指的是对于何时施加锁或者释放锁由存储引擎自行决定；mysql server锁指的是表级别的锁，可自行决定施加锁或释放锁，也允许显式请求加锁或释放锁；显式锁就是用户手动施加的锁，隐式锁指的是由存储引擎根据需要自行施加的锁；对于innodb存储引擎来讲，它支持事务，行级锁；而早期的MyISAM存储引擎它不支持事务，对锁的粒度是表级锁，不支持行级锁；

　　显示锁的使用

　　1）LOCK TABLES

　　　　指令使用语法：

　　　　LOCK TABLES  tbl_name  read|write, tbl_name read|write, ...

　　示例：

　　提示：以上语句表示对test_tb这张表施加读锁操作，这意味着其他用户或进程都不能对该表进行写的操作，只能对，因为读锁上共享锁；

　　测试：对test_tb表进行写操作，看看是否能够写进去？

　　提示：从上面的提示，它告诉我们test_tb这张表施加了读锁，不允许更新；这说明施加读锁，对于写的操作就不能进行；

　　测试：对test_tb表进行对操作，看看是否能够进行呢？

　　提示：可以看到加了读锁的表，对于读操作上可以继续进行的；

　　测试：对test_tb表施加写锁

　　提示：释放锁用unlock tables即可释放刚才的读锁；

　　测试：对test_tb进行写操作，看看是否能够进行？

　　提示：在当前终端上是可以进行读写操作的；

　　测试：在其他终端看看是否能够对test_tb表进行读写操作呢？

　　提示：从上面的截图可以看到当我们重新启动一个终端对test_tb进行写操作，它一直处于阻塞状态；

　　提示：对于对操作也是同样的效果；一直阻塞着；

　　总结：对于施加读锁的表，是可以进行读操作的，但是不能进行写操作，包括当前终端也不能写操作；对于施加写锁的表，在当前施加锁的终端上是可以对其进行对写操作的，但是在别的终端的对写操作都将阻塞；

　　除了以上指令来对表进行加锁外，还可以使用 flush tables指令来加读锁，具体语法请看下面；

　　FLUSH TABLES tbl_name,... [WITH READ LOCK];

　　测试：加读锁

　　提示：以上flush tables 只能加读锁，不能加写锁；

　　行级锁：SELECT cluase [FOR UPDATE | LOCK IN SHARE MODE]

　　行级排它锁

　　提示：以上红框中的内容就是给第一行加了一个排它锁，这意味着该事务没有提交，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排它锁的事务是可以对数据就行读取和修改。

　　提示：可以看到我们重新启动一个事务，然后对第一行进行更新操作，语句就阻塞在哪里了；说明行级排它锁对其他事务来讲是不允许对加锁的行进行写操作；默认情况updeate更新会默认加上排它锁，因为对于第一行来讲，已经有一个排它锁了，所以其他事务就不能对其在加其他锁；而对于select语句来讲，它执行时默认不会加任何锁的，所以我们执行select语句是可以正常的查看第一行数据；如果我们在select后面手动加锁，它也会阻塞的；如下

　　提示：从上面的截图信息可以看到，我们手动加上排它锁，查询语句也不会顺利执行；从上面信息还可以了解到，我们对第二行也没法进行操作，这又是为什么呢？

　　提示：我们查看test_tb这张表上的索引信息，发现没有索引，然后我们在上面创建了一个索引；创建索引时，需要把前面的事务提交了，才可创建成功，否则一直锁在哪里的；接下来我们在创建一个事务，把第一行加上排它锁，然后在对第二行操作看看是否还会一直阻塞呢？

　　提示：可以看到当我们创建就了索引后，再对第一行加锁，然后更新第二行就可以正常更新了 ，对第一行还是处于阻塞状态；这说明innodb存储引擎的行级锁的实现其实是依靠其对应的索引，所以如果操作的行并没有用到索引，那么用的还是表级锁。施加行级排它锁后，其他事务将不能对其在施加任何锁；那么对于获取到排它锁的是否能够正常操作呢？

　　提示：对于获取到排它锁的事务，是可以正常更新的；也可以给对应行施加其他锁；

　　行级共享锁

　　提示：以上红框中的内容表示给第一行施加共享锁，这意味着在其他事务锁可以共享这把锁看到数据，但是不能更新修改数据；

　　测试：在当前事务中更新数据，看看是否可更新？

　　提示：在当前事务中是可以正常修改数据的；也能正常查看数据；

　　在其他事务中修改数据，看看是否可修改？

　　提示：可以看到在其他事务中，就不能对有共享锁的行进行修改操作，但是可以正常读；

　　总结：innodb存储引擎的行级锁依赖索引，如果没有索引，就相当于表级锁；对于排它锁来讲，获取到排它锁的事务是可以正常修改更新以及加共享锁，对于没有获取到排它锁的事务，是不能够对有锁的行进行修改更新以及加锁的操作；对于共享锁来讲，对于当前事务（加锁操作的事务）是可以正常修改更新有锁的行，对于其他事务，是不可修改和更新有锁的行；