一、锁机制和Mysql锁介绍
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源(如CPU、RAM、I/O等)的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。
MySQL相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)；BDB存储引擎采用的是页面锁(page-level locking)，但也支持表级锁；InnoDB存储引擎既支持行级锁(row-level locking)，也支持表级锁，但默认情况下是采用行级锁。
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有 并发查询的应用，如一些在线事务处理(OLTP)系统。
二、MyISAM表锁
MySQL的表级锁有两种模式：
表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。
执行select语句对MyISAM表的读操作会自动加读锁，不会阻塞其他用户对同一表的读请求，但会阻塞；在执行更新操作 (UPDATE、DELETE、INSERT 等)前，会自动给涉及的表加写锁，对同一表的写请求,对 MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。
给MyISAM表显示加锁，一般是为了在一定程度模拟事务操作，实现对某一时间点多个表的一致性读取。例如， 有一个订单表orders，其中记录有各订单的总金额total，同时还有一个订单明细表order_detail，其中记录有各订单每一产品的金额小计 subtotal，假设我们需要检查这两个表的金额合计是否相符，可能就需要执行如下两条SQL：
Select sum(total) from orders;
Select sum(subtotal) from order_detail;这时，如果不先给两个表加锁，就可能产生错误的结果，因为第一条语句执行过程中，order_detail表可能已经发生了改变。因此，正确的方法应该是：
读锁例子
Lock tables orders read local, order_detail read local;
Select sum(total) from orders;
Select sum(subtotal) from order_detail;
Unlock tables;写锁例子
lock table film_text write;
select * from film_text where film_id=999G;
insert into film_text(film_id,title) value (1001,'Test');
update film_text set where film_id='1001';
UNLOCK TABLES；注意：
在执行 LOCK TABLES 后，只能访问显式加锁的这些表，不能访问未加锁的表;
四、InnoDB锁
InnoDB与MyISAM的最大不同有两点：一是支持事务(TRANSACTION)；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。
1、事务(Transaction)及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元，事务具有4属性，通常称为事务的ACID属性。
原子性(Actomicity)：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
一致性(Consistent)：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以操持完整性；事务结束时，所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。
隔离性(Isolation)：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的"独立"环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
持久性(Durable)：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
2、并发事务带来的问题
相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持可以支持更多的用户。但并发事务处理也会带来一些问题，主要包括以下几种情况。
更新丢失(Lost Update)：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新。例如，两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改保存其更改副本的编辑人员覆盖另一个编辑人员所做的修改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。
脏读(Dirty Reads)：一个事务正在对一条记录做修改，在这个事务并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些"脏"的数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做"脏读"。
不可重复读(Non-Repeatable Reads)：一个事务在读取某些数据已经发生了改变、或某些记录已经被删除了！这种现象叫做"不可重复读"。
幻读(Phantom Reads)：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为"幻读"。
3、事务隔离级别
在并发事务处理带来的问题中，"更新丢失"通常应该是完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
"脏读"、"不可重复读"和"幻读"，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式，基本可以分为以下两种。
一种是在读取数据前，对其加锁，阻止其他事务对数据进行修改。
另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot)，并用这个快照来提供一定级别(语句级或事务级)的一致性读取。从用户的角度，好像是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据多版本并发控制(ＭultiVersion Concurrency Control，简称MVCC或MCC)，也经常称为多版本数据库。
五、InnoDB的行锁模式及加锁方法
InnoDB共有七种类型的锁：
共享锁(Shared Locks)：又称读锁，允许其他事务读一行，组织其他事务为这一行增加排他锁
select语句默认不加锁，加共享锁可以使用select … lock in share mode语句
排它锁(Exclusive Locks)：又称写锁，阻止其他事务为这一回加读锁和写锁
update,delete,insert都会自动给涉及到的数据加上排他锁
加排他锁可以使用select …for update。
意向锁(Intention Locks)：InnoDB为了支持多粒度锁机制(multiple granularity locking)，即允许行级锁与表级锁共存，而引入了意向锁(intention locks)。意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。
意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁；
意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁；
加锁的语法为：
select ... lock in share mode; 要设置IS锁；
select ... for update; 要设置IX锁；记录锁(Record Locks)：记录锁，它封锁索引记录
例如(其中id为pk)：
create table lock_example(id smallint(10),name varchar(20),primary key id)engine=innodb;
select * from t where id=1 for update;其实这里是先获取该表的意向排他锁(IX)，再获取这行记录的排他锁(我的理解是因为这里直接命中索引了)，以阻止其他事务插入，更新，删除id=1的这一行
间隙锁(Gap Locks)：间隙锁，它封锁索引记录中的间隔，或者第一条索引记录之前的范围，又或者最后一条索引记录之后的范围。
select * from lock_example
where id between 8 and 15
for update;间隙锁的主要目的，就是为了防止其他事务在间隔中插入数据，以导致"不可重复读"。如果把事务的隔离级别降级为读提交(Read Committed, RC)，间隙锁则会自动失效。
临键锁(Next-key Locks)：临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间。
事务A执行如下语句，未提交：
select * from lock_example where id = 20 for update;事务B开始，执行如下语句，会阻塞：
insert into lock_example values('zhang',15);插入意向锁(Insert Intention Locks)：是间隙锁(Gap Locks)的一种(所以，也是实施在索引上的)，它是专门针对insert操作的。多个事务，在同一个索引，同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此。
举个例子(表依然是如上的例子lock_example，数据依然是如上)，事务A先执行，在10与20两条记录中插入了一行，还未提交：
insert into t values(11, xxx);事务B后执行，也在10与20两条记录中插入了一行：
insert into t values(12, ooo);因为是插入操作，虽然是插入同一个区间，但是插入的记录并不冲突，所以使用的是插入意向锁，此处A事务并不会阻塞B事务。
自增锁(Auto-inc Locks)：是一种特殊的表级别锁(table-level lock)，专门针对事务插入AUTO_INCREMENT类型的列。最简单的情况，如果一个事务正在往表中插入记录，所有其他事务的插入必须等待，以便第一个事务插入的行，是连续的主键值。
举个例子(表依然是如上的例子lock_example)，但是id为AUTO_INCREMENT，数据库表中数据为：
1, zhangsan
2, lisi
3, wangwu
事务A先执行，还未提交： insert into t(name) values(xxx);
事务B后执行： insert into t(name) values(ooo);
此时事务B插入操作会阻塞，直到事务A提交。
六、InnoDB锁状态查看
可以通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：
mysql> show status like '%lock%';+------------------------------------------+---------+| Variable_name | Value |+------------------------------------------+---------+| Com_lock_tables | 0 || Com_unlock_tables | 0 || Innodb_row_lock_current_waits | 0 || Innodb_row_lock_time | 3946985 || Innodb_row_lock_time_avg | 1558 || Innodb_row_lock_time_max | 121788 || Innodb_row_lock_waits | 2532 || Key_blocks_not_flushed | 0 || Key_blocks_unused | 26716 || Key_blocks_used | 2660 || Performance_schema_locker_lost | 0 || Performance_schema_rwlock_classes_lost | 0 || Performance_schema_rwlock_instances_lost | 0 || Qcache_free_blocks | 27343 || Qcache_total_blocks | 61962 || Table_locks_immediate | 8504599 || Table_locks_waited | 2 |+------------------------------------------+---------+nnoDB 的行级锁定状态变量不仅记录了锁定等待次数，还记录了锁定总时长，每次平均时长，以及最大时长，此外还有一个非累积状态量显示了当前正在等待锁定的等待数量。对各个状态量的说明如下：
InnoDB_row_lock_current_waits：当前正在等待锁定的数量；
InnoDB_row_lock_time：从系统启动到现在锁定总时间长度；
InnoDB_row_lock_time_avg：每次等待所花平均时间；
InnoDB_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
InnoDB_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是InnoDB_row_lock_time_avg(等待平均时长)，InnoDB_row_lock_waits(等待总次数)以及InnoDB_row_lock_time(等待总时长)这三项。尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。
如果发现锁争用比较严重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，还可以通过设置InnoDB Monitors 来进一步观察发生锁冲突的表、数据行等，并分析锁争用的原因。
七、mysql查看死锁和解除锁
解除正在死锁的状态有两种方法：
第一种：
1.查询是否锁表
show OPEN TABLES where In_use > 0;2.查询进程(如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程)
show processlist3.杀死进程id(就是上面命令的id列)
kill id第二种：
1.查看下在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;2.杀死进程id(就是上面命令的trx_mysql_thread_id列)
kill 线程ID
例子：
查出死锁进程：SHOW PROCESSLIST
杀掉进程 KILL 420821;
其它关于查看死锁的命令：
1：查看当前的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;2：查看当前锁定的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;3：查看当前等锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
