一.锁机制为什么是数据库非常重要的内容，那么看一下数据库并发的问题你就知道为什么了：
数据库并发的问题
1.1脏读
脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
1.2不可重复读：
是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。（即不能读到相同的数据内容）
例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。
1.3幻读:
是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好像发生了幻觉一样。
1.4丢失更新
当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。
e.g.事务A和事务B同时修改某行的值，
1.事务A将数值改为1并提交
2.事务B将数值改为2并提交。
这时数据的值为2，事务A所做的更新将会丢失。
select old_attributes from table where primary_key = ? ---step1 attributes = merge(old_attributes,new_attributes) ----step2 update table set attributes_column = attributes where primary_key = ? ----step3
但是这样的话，存在一个丢失更新的问题，两个线程ThreadA 和 ThreadB 同时运行到了step1得到相同的old_attributes,
然后同时做step2,最后ThreadA先做step3,而ThreadB后做step3,这样ThreadB就把ThreadA的属性更新给丢失了！
解决方法：
基本两种思路，一种是悲观锁，另外一种是乐观锁； 简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败；另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作。
1.1.1 悲观锁
a）传统的悲观锁法（不推荐）：
以上面的例子来说明，在弹出修改工资的页面初始化时（这种情况下一般会去从数据库查询出来），在这个初始化查询中使用select ……for update nowait， 通过添加for update nowait语句，将这条记录锁住，避免其他用户更新，从而保证后续的更新是在正确的状态下更新的。然后在保持这个链接的状态下，在做更新提交。当然这个有个前提就是要保持链接，就是要对链接要占用较长时间，这个在现在web系统高并发高频率下显然是不现实的。
b）现在的悲观锁法（推荐优先使用）：
在修改工资这个页面做提交时先查询下，当然这个查询必须也要加锁（select ……for update nowait），有人会说，在这里做个查询确认记录是否有改变不就行了吗，是的，是要做个确认，只是你不加for update就不能保证你在查询到更新提交这段时间里这条记录没有被其他会话更新过，所以这种方式也需要在查询时锁定记录，保证在这条记录没有变化的基础上再做更新，若有变化则提示告知用户。
1.1.2. 乐观锁
a）旧值条件（前镜像）法：
就是在sql更新时使用旧的状态值做条件，SQL大致如下 Update table set col1 = newcol1value， col2 = newcol2value…。 where col1 = oldcol1value and col2 = oldcol2value…。，在上面的例子中我们就可以把当前工资作为条件进行更新，如果这条记录已经被其他会话更新过，则本次更新了0行，这里我们应用系统一般会做个提示告知用户重新查询更新。这个取哪些旧值作为条件更新视具体系统实际情况而定。（这种方式有可能发生阻塞，如果应用其他地方使用悲观锁法长时间锁定了这条记录，则本次会话就需要等待，所以使用这种方式时最好统一使用乐观锁法。）
b）使用版本列法（推荐优先使用）：
其实这种方式是一个特殊化的前镜像法，就是不需要使用多个旧值做条件，只需要在表上加一个版本列，这一列可以是NUMBER或 DATE/TIMESTAMP列，加这列的作用就是用来记录这条数据的版本（在表设计时一般我们都会给每个表增加一些NUMBER型和DATE型的冗余字段，以便扩展使用，这些冗余字段完全可以作为版本列用），在应用程序中我们每次操作对版本列做维护即可。在更新时我们把上次版本作为条件进行更新。在对一行进行更新的时候 限制条件=主键+版本号，同时对记录的版本号进行更新。
start transaction; select attributes, old_version from table where primary_key = ? attribute Merge operations update table set version = old_verison + 1 , attributes_column = attributes_value where primary_key = ? and version = old_version commit;
事务提交以后，看最后一步更新操作的记录更新数是否为1，如果不是，则在业务上提示重试。（表明此时更新操作的并发度较高。）
在用户并发数比较少且冲突比较严重的应用系统中选择悲观锁b方法，其他情况首先乐观锁版本列法。
SQL Server中指定锁：
SELECT * FROM table WITH (HOLDLOCK) ----其他事务可以读取表，但不能更新删除
SELECT * FROM table WITH (TABLOCKX) -----其他事务不能读取表,更新和删除
不同的数据库锁的类型有差别，具体需要查询各自的api doc。
二.数据库隔离机制
谈到数据库隔离机制，就不得不先说事务transaction。数据库事务有严格的定义，它必须同时满足4个特性：原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabiliy），简称为ACID。
原子性：保证事务中的所有操作全部执行或全部不执行。例如执行转账事务，要么转账成功，要么失败。成功，则金额从转出帐户转入到目的帐户，并且两个帐户金额将发生相应的变化；失败，则两个账户的金额都不变。不会出现转出帐户扣了钱，而目的帐户没有收到钱的情况。
一致性：保证数据库始终保持数据的一致性——事务操作之前是一致的，事务操作之后也是一致的，不管事务成功与否。如上面的例子，转账之前和之后数据库都保持数据上的一致性。
隔离性：多个事务并发执行的话，结果应该与多个事务串行执行效果是一样的。在并发数据操作时，不同的事务拥有各自的数据空间，其操作不会对对方产生干扰。隔离允许事务行为独立或隔离于其他并发运行的事务。通过控制隔离，每个事务在其行动时间里都像是修改数据库的惟一事务。一个事务与其他事务隔离的程度称为隔离级别。数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱。
持久性：持久性表示事物操作完成之后，对数据库的影响是持久的，即使数据库因故障而受到破坏，数据库也应该能够恢复。通常的实现方式是采用日志。
ANSI/ISO SQL92标准定义了一些数据库操作的隔离级别。每种隔离级别指定当前事务执行时所不允许的交互作用类型，即事务间是否相互隔离，或它们是否可以读取或更新被另一事务所使用的信息。较高隔离级别包括由较低级别所施加的限制。
不同的隔离等级对应的将会导致的数据库并发的问题总结如下：
| 隔离等级 | 脏读 | 不可重复读 | 幻读 |
| 读未提交RU | Yes | Yes | Yes |
| 读已提交RC | No | Yes | Yes |
| 可重复读RR | No | No | Yes |
| 串行化 | No | No | No |
因此，对于不同的隔离等级，需要在事务中主动加锁，以避免这些并发的问题。
三. 数据库的锁机制
各种大型数据库所采用的锁的基本理论是一致的，但在具体实现上各有差别。
SQL Server更强调由系统来管理锁。在用户有SQL请求时，系统分析请求，自动在满足锁定条件和系统性能之间为数据库加上适当的锁，同时系统在运行期间常常自动进行优化处理，实行动态加锁。
SQLite采用粗放型的锁。当一个连接要写数据库，所有其它的连接被锁住，直到写连接结束了它的事务。SQLite有一个加锁表，来帮助不同的写数据库都能够在最后一刻再加锁，以保证最大的并发性。
Mysql数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。
总的来说，MysqlL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。
对于一般的用户而言，通过系统的自动锁定管理机制基本可以满足使用要求。 但是涉及到写操作，还是一定要理解隔离机制和并发可能带来的问题，在事务中或者SQL中加入锁机制。对于数据库的死锁，一般数据库系统都会有一套机制去解锁，一般不会造成数据库的瘫痪，但解锁的过程会造成数据库性能的急速下降，反映到程序上就会造成程序的反应性能的下降，并且会造成程序有的操作失败。
行级锁（引擎 INNODB ， 单独的一行记录加锁）:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页级锁（引擎 BDB）：开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般。
表级锁（引擎 MyISAM ）：开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低。
MySQL 5.1支持对MyISAM和MEMORY表进行表级锁定，对BDB表进行页级锁定，对InnoDB表进行行级锁定。
InnoDB使用行锁定，BDB使用页锁定。对于这两种存储引擎，都可能存在死锁。这是因为，在SQL语句处理期间，InnoDB自动获得行锁定和BDB获得页锁定，而不是在事务启动时获得。
三种锁各有各的特点，若仅从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如WEB应用；行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。
MySQL表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。什么意思呢，就是说对MyISAM表进行读操作时，它不会阻塞其他用户对同一表的读请求，但会阻塞 对同一表的写操作；而对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作。
InnoDB锁与MyISAM锁的最大不同在于：一是支持事务（TRANCSACTION），二是采用了行级锁。我们知道事务是由一组SQL语句组成的逻辑处理单元，其有四个属性（简称ACID属性）
InnoDB有两种模式的行锁：
1）共享锁：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
( Select * from table_name where ......lock in share mode)
2）排他锁：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和 排他写锁。(select * from table_name where.....for update)
为了允许行锁和表锁共存，实现多粒度锁机制；同时还有两种内部使用的意向锁（都是表锁），分别为意向共享锁和意向排他锁。
InnoDB行锁是通过给索引项加锁来实现的，即只有通过索引条件检索数据，InnoDB才使用行级锁，否则将使用表锁！
MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。锁模式的兼容性如下表所示。
|
请求锁模式
是否兼容
当前锁模式
|
None | 读锁 | 写锁 |
| 读锁 | 是 | 是 | 否 |
| 写锁 | 是 | 否 | 否 |
悲观锁
顾名思义就是采用一种悲观的态度来对待事务并发问题，我们认为系统中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。
假如我们数据库事务的隔离级别设置为读取已提交或者更低，那么通过悲观锁，我们控制了不可重复读的问题，但是不能避免幻影读的问题，因为要想避免我们就需要设置数据库隔离级别为Serializable,而一般情况下我们都会采取读取已提交或者更低隔离级别，并配合乐观或者悲观锁来实现并发控制，所以幻影读问题是不能避免的，如果想避免幻影读问题，那么你只能依靠数据库的serializable隔离级别（幸运的是幻影读问题一般情况下不严重）
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
乐观锁
乐观锁是在同一个数据库事务中我们常采取的策略，因为它能使得我们的系统保持高的性能的情况下，提高很好的并发访问控制。乐观锁，顾名思义就是保持一种乐观的态度，我们认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。它的基本思想就是每次提交一个事务更新时，我们想看看要修改的东西从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。（因此能够解决第二类丢失修改问题）
因为乐观锁其实并不会锁定任何记录，所以如果我们数据库的事务隔离级别设置为读取已提交或者更低的隔离界别，那么是不能避免不可重复读问题的（因为此时读事务不会阻塞其它事务），所以采用乐观锁的时候，系统应该要容许不可重复读问题的出现。
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。
区别
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。