数据库锁机制：
数据库并发需要使用事务来控制，事务并发问题需要数据库锁来控制，所以数据库锁是跟并发控制和事务联系在一起的。
平时会经常看到或者听到数据库锁有“共享锁”，“排它锁”，“互斥锁”，“写锁”，“读锁”，“悲观锁”，“乐观锁”，“行级锁”，“表级锁”，“页级锁”等，
同时我们还会常看到“丢失修改“，”不可重复读“，”读脏数据“这三个术语，他们究竟是什么关系以及怎么理解呢，下面就来介绍一下他们。
1：先说悲观锁和乐观锁
并发控制一般采用三种方法，分别是【乐观锁】和【悲观锁】以及【时间戳】。
1：乐观锁认为：在读数据的时候，别人不会去写自己所读的数据；
2：悲观锁就刚好相反，觉得自己读数据库的时候，别人可能刚好在写自己刚读的数据，其实就是持一种比较保守的态度；
3：时间戳就是不加锁，通过时间戳来控制并发出现的问题。
简单理解：
悲观锁就是在读取数据的时候，为了不让别人修改自己读取的数据，就会先对自己读取的数据加锁，只有自己把数据读完了，才允许别人修改那部分数据，或者反过来说，就是自己修改某条数据的时候，不允许别人读取该数据，只有等自己的整个事务提交了，才释放自己加上的锁，才允许其他用户访问那部分数据。
乐观锁就比较简单了，就是不做控制，这只是一部分人对于并发所持有的一种态度而已。
时间戳就是在数据库表中单独加一列时间戳，比如“TimeStamp”，每次读出来的时候，把该字段也读出来，当写回去的时候，把该字段加1，提交之前 ，跟数据库的该字段比较一次，如果比数据库的值大的话，就允许保存，否则不允许保存，这种处理方法虽然不使用数据库系统提供的锁机制，但是这种方法可以大大提高数据库处理的并发量，因为这种方法可以避免了长事务中的数据库加锁开销（操作员A 和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能现。
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户 余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如 将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途 径，而不是将数据库表直接对外公开）。
以上悲观锁所说的加“锁”，其实分为几种锁，分别是：排它锁和共享锁，其中排它锁又称为写锁，共享锁又称为读锁。
(ps.可以参考此文 “http://blog.sina.com.cn/s/blog_548bd2090100ir7k.html”)
2：悲观锁之：排他锁和共享锁
默认来说，当sql脚本修改更新某条记录的时候，会给该条记录加X锁（排他锁），读的话加的是S锁（共享锁）。
共享锁和排它锁是具体的锁，是数据库机制上的锁，存在以下关系：
（x表示是排它锁(Exclusive)，s表示共享锁(Share)，Y表示yes，N表示no）
上图表示可以共存的锁，如，第二行表示，一个事务T1给某数据加了X锁，则事务T2就不能再给那数据加X锁了，同时也不能再加S锁了，只有到T1事务提交完成之后，才可以。默认来说，当sql脚本修改更新某条记录的时候，会给该条记录加X锁，读的话加的是S锁。
另外，并发操作会导致数据的不一致性，主要包括“丢失数据”，“不可重复读”，“读脏数据等。
还有就是，并发控制会造成活锁和死锁，就像操作系统那样，会因为互相等待而导致。
活锁指的是T1封锁了数据R，T2同时也请求封锁数据R，T3也请求封锁数据R，当T1释放了锁之后，T3会锁住R，T4也请求封锁R，则T2就会一直等待下去，这种处理方法就是采用“先来先服务”策略；
死锁就是我等你，你又等我，双方就会一直等待下去，比如：T1封锁了数据R1，正请求对R2封锁，而T2封住了R2,正请求封锁R1，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防，
预防死锁的方法有：
1：一次封锁发，指的是一次性把所需要的数据全部封锁住，但是这样会扩大了封锁的范围，降低系统的并发度；
2：顺序封锁发，指的是事先对数据对象指定一个封锁顺序，要对数据进行封锁，只能按照规定的顺序来封锁，但是这个一般不大可能的，业务上很难确定。
诊断和判断死锁：
诊断和判断死锁有两种方法，一是【超时法】，二是【等待图法】。
超时法就是如果某个事物的等待时间超过指定时限，则判定为出现死锁；
等待图法指的是如果事务等待图中出现了回路，则判断出现了死锁。
解决死锁的方法：
对于解决死锁的方法，只能是撤销一个处理死锁代价最小的事务，释放此事务持有的所有锁，同时对撤销的事务所执行的数据修改操作必须加以恢复。
3：行级锁
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁 和 排他锁。
特点
开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
4：表级锁
表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
特点
开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
5：页级锁
页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。BDB支持页级锁
特点
开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
6：Innodb中的行锁与表锁
在Innodb引擎中既支持行锁也支持表锁，那么什么时候会锁住整张表，什么时候或只锁住一行呢？
InnoDB行锁是通过给数据库的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。
InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。
行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。
行级锁的缺点是：由于需要请求大量的锁资源，所以速度慢，内存消耗大。
行级锁与死锁
MyISAM中是不会产生死锁的（因为他只支持表锁），因为MyISAM总是一次性获得所需的全部锁，要么全部满足，要么全部等待。而在InnoDB中，锁是逐步获得的，就造成了死锁的可能。
在MySQL中，行级锁并不是直接锁记录，而是锁索引。
索引分为主键索引和非主键索引两种：
如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；
如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。
当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。
发生死锁后，InnoDB一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。
有多种方法可以避免死锁，这里只介绍常见的三种
1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
7：MySQL中的共享锁与排他锁
共享锁(Share Lock)
共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获取共享锁的事务只能读数据，不能修改数据。
用法
SELECT ... LOCK IN SHARE MODE;
在查询语句后面增加LOCK IN SHARE MODE，Mysql会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。其他线程也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。
排他锁（eXclusive Lock）
排他锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获取排他锁的事务既能读数据，又能修改数据。
用法
SELECT ... FOR UPDATE;
在查询语句后面增加FOR UPDATE，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。
因此，共享锁和排他锁那个关系图很重要。（本文中第一个图）
总结：
对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；
对于一般的select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。
共享锁：SELECT ... LOCK IN SHARE MODE;
排他锁：SELECT ... FOR UPDATE;
8：乐观锁和悲观锁
乐观锁和悲观锁和时间戳是并发控制的主要手段。
注意：
不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈
其实，在DBMS（数据库管理系统）中，悲观锁正是利用数据库本身提供的锁机制来实现的。
在数据库中，悲观锁的流程如下：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
MySQL InnoDB中使用悲观锁
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;
//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;
上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。
此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。
这样我们可以保证当前的数据不会被其它事务修改。
注意一点：
上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。
但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；
另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数
乐观锁
它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。
数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
使用版本号实现乐观锁
使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。
1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
本文中部分内容是截取网上比较好的一些博客：
https://blog.csdn.net/lexang1/article/details/52248686
9：死锁
死锁得在拿出来重新说下，面试问到的概率也比较大。因此我这块在详细的说下死锁的一些东西。
例子：两个事务，事务都有两个操作。当同时发生时，事务A锁定first表，事务B锁定second表，导致了死锁。
解决方法：
理论上预防死锁的发生就是要破坏产生死锁的条件。
所以数据库系统一般采用诊断并解除死锁的方法。
死锁的诊断与解除：数据库系统中诊断死锁的方法与操作系统类似，一般是用超时法或事务等待图法。
1.超时法：
指的是如果一个事务的等待时间超过了规定的时限，就认为发生死锁。
不足：
（一）有可能误判死锁，事务因为其他原因使等待时机超过时限。
（二）时限若设置得太长，死锁发生后不能及时发现。
2.等待图法：
指的是用事务等待图动态反应所有事务的等待情况。
事务等待图是一个有向图G=(T,U)，其中T为结点的集合，每个结点表示正在运行的事务。U为边的集合，每条边表示事务等待的情况。若T1等待T2，则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。
以上就是死锁的诊断与解除了。而且DBMS并发控制子系统一旦检测到系统中存在死锁，就会设法解除。通常是选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有的所有的锁，使其他事务能继续运行下去。（而且要对撤销的事务所执行的数据修改操作进行恢复）
比较常用的减少死锁产生概率
a. 类似业务模块中，尽可能按照相同的访问顺序来访问，防止产生死锁；
b. 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
c. 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
顺带在说下火锁：
上文也有说过，这里在提一下：
活锁指的是T1封锁了数据R，T2同时也请求封锁数据R，T3也请求封锁数据R，当T1释放了锁之后，T3会锁住R，T4也请求封锁R，则T2就会一直等待下去，这种处理方法就是采用“先来先服务”策略；
死锁就是我等你，你又等我，双方就会一直等待下去，比如：T1封锁了数据R1，正请求对R2封锁，而T2封住了R2,正请求封锁R1，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防，
10：银行家算法避免死锁
银行家在客户申请的贷款数量不超过自己拥有的最大值时，都应尽量满足客户的需要。
银行家算法是一种最有代表性的避免死锁的算法。在避免死锁方法中允许进程动态地申请资源，但系统在进行资源分配之前，应先计算此次分配资源的安全性，若分配不会导致系统进入不安全状态，则分配，否则等待。为实现银行家算法，系统必须设置若干数据结构。
【安全序列】
安全序列是指一个进程序列{P1，…，Pn}是安全的，即对于每一个进程Pi(1≤i≤n），它以后尚需要的资源量不超过系统当前剩余资源量与所有进程Pj (j < i )当前占有资源量之和。（即在分配过程中，不会出现某一进程后续需要的资源量比其他所有进程及当前剩余资源量总和还大的情况）
注：存在安全序列则系统是安全的，如果不存在则系统不安全，但不安全状态不一定引起死锁。
原理过程：
系统给当前进程分配资源时，先检查是否安全：
在满足当前的进程X资源申请后，是否还能有足够的资源去满足下一个距最大资源需求最近的进程（如某进程最大需要5个单位资源，已拥有1个，还尚需4个），若可以满足，则继续检查下一个距最大资源需求最近的进程，若均能满足所有进程，则表示为安全，可以允许给当前进程X分配其所需的资源申请，否则让该进程X进入等待。
（注：检查过程中，每满足一个进程，则进行下个检查时，当前可用资源为回收上一个进程资源的总值，每满足一个进程表示此进程已结束，资源可回收。）
（银行家算法在避免死锁角度上非常有效，但是需要在进程运行前就知道其所需资源的最大值，且进程数也通常不是固定的，因此使用有限，但从思想上可以提供了解，可以转换地应用在其他地方）
11：数据库如何提高并发效率
1：悲观锁：利用数据库本身的锁机制实现。通过上面对数据库锁的了解，可以根据具体业务情况综合使用事务隔离级别与合理的手工指定锁的方式比如降低锁的粒度等减少并发等待。
悲观锁带来的性能问题。我们试想一个场景：如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果？所以我们这个时候可以使用乐观锁。
2：乐观锁：利用程序处理并发。原理都比较好理解，基本一看即懂。方式大概有以下3种
对记录加版本号.
对记录加时间戳.
对将要更新的数据进行提前读取、事后对比。
像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
之后我在写一篇大并发下数据怎么处理（自己的理解），
其实基本上都涉及不到数据库的，百万级别可以在sql或者数据库锁这方面优化，
但是如果千万呢？亿呢？基本上就要想办法考虑架构了。