什么是锁？
锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。
分析系统上的表锁定争夺
show status like 'table%';
mysql> show status like 'table%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Table_locks_immediate | 9 |（表示可以立即获取锁的次数）
| Table_locks_waited | 0 | （表示不能立即获取锁，需要等待锁的次数;）
| Table_open_cache_hits | 0 |
| Table_open_cache_misses | 0 |
| Table_open_cache_overflows | 0 |
Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。
针对mysql俩种存储引擎学习
1.MyISAM存储引擎只支持表锁
MySQL的表锁有两种模式：
- 表共享读锁 （Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
- 表独占写锁 （Table Write Lock）：会阻塞其他用户对同一表的读和写操作；
MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后， 只有持有锁的线程可以对表进行更新操作。 其他线程的读、 写操作都会等待，直到锁被释放为止。例子如下：
MyISAM存储引擎的写阻塞读例子
创建一个MyISAM引擎表t;
create table t(id int,name varchar(20))engine=MyISAM;
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁
特别注意
1.加读锁语句:lock table t read;
2.在lock table t read时加“local”选项：如：lock tables t read local;
作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录（好像只能是加读锁可以加这个选项）
用户1：
mysql> lock table t write local;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'local' at line 1
mysql> lock table t read local;
Query OK, 0 rows affected (0.00 sec)
用户2
mysql> insert into t values(2,'小花');
Query OK, 1 row affected (0.00 sec)
可以看到能够执行插入操作，但是不能执行修改操作。
mysql> updata t set name='小红' where id = 2;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'updata t set name='小红' where id = 2' at line 1
3.在用 lock table给表显式加表锁时，必须同时取得所有涉及到表的锁，并且MySQL不支持锁升级。
也就是说，在执行lock table后，只能访问显式加锁的这些表，不能访问未加锁的表；
同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。
其实，在自动加锁的情况下也基本如此，MyISAM总是一次获得SQL语句所需要的全部锁。
这也正是MyISAM表不会出现死锁（Deadlock Free）的原因
mysql> select * from a;
ERROR 1100 (HY000): Table 'a' was not locked with LOCK TABLES
4.加锁查询时，不仅需要一次锁定用到的所有表，别名也需要加锁，不然也会报错！举例：
mysql> lock table t read;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t p where p.id = 1;
ERROR 1100 (HY000): Table 'p' was not locked with LOCK TABLES
mysql> lock table t as p read;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t p where p.id = 1;
+------+--------+
| id | name |
+------+--------+
| 1 | 小明 |
+------+--------+
MyISAM的锁调度
MyISAM存储引擎的读锁和写锁是互斥的，读写操作是串行的。
那么，一个进程请求某个 MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？
答案是写进程先获得锁。因为MySQL认为写请求一般比读请求要重要。
当然可以通过一些设置来调节MyISAM 的调度行为。
2.InnoDB锁问题
innoDB与MyISAM的最大不同有两点：
一是支持事务
二是采用了行级锁。
ACID 事务
A事务的原子性 (Atomicity)：指一个事务要么全部执行，要么不执行。也就是说一个事务不可能只执行了一半就停止了。比如你从取款机取钱，这个事务可以分成两个步骤：1）划卡，2）出钱。不可能划了卡，而钱却没出来，这两步必须同时完成，要么就不完成。
C事务的一致性 (Consistency)：指事务的运行并不改变数据库中数据的一致性。例如，完整性约束了 a+b=10，一个事务改变了 a，那么 b 也应该随之改变。
I独立性 (Isolation）：事务的独立性也有称作隔离性，是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。
D持久性 (Durability）：事务的持久性是指事务执行成功以后，该事务所对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚。事务隔离
MySQL 的事务隔离是在MySQL配置文件里添加的，在文件的最后添加：transaction-isolation = REPEATABLE-READ
可用的配置值
READ-UNCOMMITTED
READ-COMMITTED
REPEATABLE-READ
SERIALIZABLE。
READ-UNCOMMITTED：未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）。
READ-COMMITTED：提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读）。
REPEATABLE-READ：可重复读，默认级别，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读）。
SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。
脏读 ：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。
不可重复读 ：是指在一个事务内，多次读同一数据。
幻读 ：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了。
“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。更新丢失
防止更新丢失应该是应用的责任：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题－－最后的更新覆盖了由其他事务所做的更新。例如，两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖另一个编辑人员所做的更改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。
获取InnoDB行锁争用情况
show status like 'innodb_row_lock%';
mysql> show status like 'innodb_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+-------------------------
InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高.则锁争用比较严重
InnoDB实现了两种类型的行锁
- 共享锁（S)
事务拿到某一行记录的共享锁，才可以读取这一行；
多个事务可以拿到一把共享锁，你读我也读可以并行 - 排他锁（X)
事务拿到某一行记录的排它锁，才可以修改或者删除这一行；
只有一个事务可以拿到排它锁，你写我也写/你读我却写必须互斥；
意向锁
意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。意向锁有这样一些特点：
1.首先，意向锁，是一个表级别的锁（table-level locking）；
2.意向锁分为：
- 意向共享锁（IS）例如：
select ... lock in share mode要设置意向共享锁； - 意向排它锁（IX）例如：
select ... for update要设置意向排它锁；
意向锁协议：
事务要获得某些行的 共享锁(S) 锁，必须先获得表的 意向共享锁(IS） 锁
事务要获得某些行的 排他锁(X) 锁，必须先获得表的 意向排它锁(IX） 锁
由于意向锁仅仅表明意向，它其实是比较弱的锁，意向锁之间并不相互互斥，而是可以并行
InnoDB存储引擎的共享锁例子
set autocommit = 0;是什么？
InnoDB存储引擎的排他锁例子
InnoDB行锁实现方式
这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
$\color{#FF0000}{红色字}$或$\color{rgb(255,255,0)}{黄色字}$
或
注意说明
1.在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
InnoDB存储引擎的表在不使用索引时使用表锁例子
2.由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录
但是如果是使用相同的索引键，是会出现锁冲突的
3.当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行
另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
`注意这里说的是对数据加锁就对了。`
4.即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL
通过判断不同执行计划的代价来决定的
如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引
这种情况下InnoDB将使用表锁，而不是行锁。
因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
间隙锁（Next-Key锁）
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。
举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：
Select * from emp where empid > 100 for update;
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要。有关其恢复和复制对锁机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况，在后续的章节中会做进一步介绍。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！
InnoDB存储引擎的间隙锁阻塞例子
InnoDB什么时候使用表锁
对于InnoDB表，在绝大部分情况下都应该使用行级锁，因为事务和行锁往往是我们之所以选择InnoDB表的理由。但在个别特殊事务中，也可以考虑使用表级锁。
- 第一种情况是：事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该事务的执行速度。
- 第二种情况是：事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁、减少数据库因事务回滚带来的开销。
当然，应用中这两种事务不能太多，否则，就应该考虑使用MyISAM表了。
在InnoDB下，使用表锁要注意以下两点。
（1）使用LOCK TABLES虽然可以给InnoDB加表级锁，但必须说明的是，表锁不是由InnoDB存储引擎层管理的
而是由其上一层──MySQL Server负责的，仅当autocommit=0、innodb_table_locks=1（默认设置）时
InnoDB层才能知道MySQL加的表锁，MySQL Server也才能感知InnoDB加的行锁
这种情况下，InnoDB才能自动识别涉及表级锁的死锁；否则，InnoDB将无法自动检测并处理这种死锁。
（2）在用 LOCK TABLES对InnoDB表加锁时要注意，要将AUTOCOMMIT设为0，否则MySQL不会给表加锁；
事务结束前，不要用UNLOCK TABLES释放表锁，因为UNLOCK TABLES会隐含地提交事务；
COMMIT或ROLLBACK并不能释放用LOCK TABLES加的表级锁，必须用UNLOCK TABLES释放表锁。
正确的方式见如下语句：
SET AUTOCOMMIT=0;
lock tables t1 write, t2 read, ...;
[do something with table t1 and t2 here];
commit;
unlock tables;
关于死锁
MyISAM总是一次获得所需的全部锁，要么全部满足，要么等待，因此不会出现死锁。但在InnoDB中，除单个SQL组成的事务外，锁是逐步获得的，这就决定了在InnoDB中发生死锁是可能的。如下所示的就是一个发生死锁的例子。
在上面的例子中，两个事务都需要获得对方持有的排他锁才能继续完成事务，这种循环锁等待就是典型的死锁。
发生死锁后，
InnoDB一般都能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB并不能完全自动检测到死锁，这需要通过设置锁等待超时参数innodb_lock_wait_timeout来解决。需要说明的是，这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。
避免死锁
1.在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。
2.在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
3.在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。
4.降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁（间隙锁）造成的死锁。
5.为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。
参考文章:https://blog.csdn.net/mysteryhaohao/article/details/51669741