一、相关名词
|--表级锁（锁定整个表）
|--页级锁（锁定一页）
|--行级锁（锁定一行）
|--共享锁（S锁，MyISAM 叫做读锁）
|--排他锁（X锁，MyISAM 叫做写锁）
|--悲观锁（抽象性，不真实存在这个锁）
|--乐观锁（抽象性，不真实存在这个锁)
二、InnoDB与MyISAM
Mysql 在5.5之前默认使用 MyISAM 存储引擎，之后使用 InnoDB 。查看当前存储引擎：
show variables like '%storage_engine%';
MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。
而 InnoDB 与 MyISAM 的最大不同有两点：一是 InnoDB 支持事务；二是 InnoDB 采用了行级锁。也就是你需要修改哪行，就可以只锁定哪行。
在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。因为没有了索引，找到某一条记录就得扫描全表，要扫描全表，就得锁定表。
三、共享锁与排他锁（悲观锁）
共享锁(读锁)：对某一资源加共享锁，自身可以读该资源，其他人也可以读该资源（也可以再继续加共享锁，即 共享锁可多个共存），但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为：
select * from table lock in share mode
排它锁(写锁):若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。语法为：
select * from table for update --增删改自动加了排他锁
2.下面援引例子说明（援自：http://blog.csdn.net/samjustin1/article/details/52210125）：
这里用T1代表一个数据库执行请求，T2代表另一个请求，也可以理解为T1为一个线程，T2 为另一个线程。
例1：-------------------------------------------------------------------------------------------------------------------------------------
T1:select * from table lock in share mode（假设查询会花很长时间，下面的例子也都这么假设）
T2:update table set column1='hello'
过程：
T1运行（并加共享锁)
T2运行
If T1还没执行完
T2等......
else锁被释放
T2执行
endif
T2 之所以要等，是因为 T2 在执行 update 前，试图对 table 表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。所以 T2 必须等 T1 执行完，释放了共享锁，才能加上排他锁，然后才能开始执行 update 语句。
例2：-------------------------------------------------------------------------------------------------------------------------------------
T1:select * from table lock in share mode
T2:select * from table lock in share mode
这里T2不用等待T1执行完，而是可以马上执行。
分析：
T1运行，则 table 被加锁，比如叫lockAT2运行，再对 table 加一个共享锁，比如叫lockB两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它人同时读资源，但阻止其它人修改资源。
例3：-------------------------------------------------------------------------------------------------------------------------------------
T1:select * from table lock in share mode
T2:select * from table lock in share mode
T3:update table set column1='hello'
T2 不用等 T1 运行完就能运行，T3 却要等 T1 和 T2 都运行完才能运行。因为 T3 必须等 T1 和 T2 的共享锁全部释放才能进行加排他锁然后执行 update 操作。
例4：（死锁的发生）-----------------------------------------------------------------------------------------------------------------
T1:begin transelect * from table lock in share modeupdate table set column1='hello'
T2:begin transelect * from table lock in share modeupdate table set column1='world'
假设 T1 和 T2 同时达到 select，T1 对 table 加共享锁，T2 也对 table 加共享锁，当 T1 的 select 执行完，准备执行 update 时，根据锁机制，T1 的共享锁需要升级到排他锁才能执行接下来的 update.在升级排他锁前，必须等 table 上的其它共享锁（T2）释放，同理，T2 也在等 T1 的共享锁释放。于是死锁产生了。
例5：-------------------------------------------------------------------------------------------------------------------------------------
T1:begin tranupdate table set column1='hello' where id=10
T2:begin tranupdate table set column1='world' where id=20
这种语句虽然最为常见，很多人觉得它有机会产生死锁，但实际上要看情况
|--如果id是主键（默认有主键索引），那么T1会一下子找到该条记录(id=10的记录），然后对该条记录加排他锁，T2，同样，一下子通过索引定位到记录，然后对id=20的记录加排他锁，这样T1和T2各更新各的，互不影响。T2也不需要等。
|--如果id是普通的一列，没有索引。那么当T1对id=10这一行加排他锁后，T2为了找到id=20，需要对全表扫描。但因为T1已经为一条记录加了排他锁，导致T2的全表扫描进行不下去（其实是因为T1加了排他锁，数据库默认会为该表加意向锁，T2要扫描全表，就得等该意向锁释放，也就是T1执行完成），就导致T2等待。
死锁怎么解决呢？一种办法是，如下：
例6：-------------------------------------------------------------------------------------------------------------------------------------
T1:begin tran select * from table for updateupdate table set column1='hello'
T2:begin tran select * from table for updateupdate table set column1='world'
这样，当 T1 的 select 执行时，直接对表加上了排他锁，T2 在执行 select 时，就需要等 T1 事物完全执行完才能执行。排除了死锁发生。但当第三个 user 过来想执行一个查询语句时，也因为排他锁的存在而不得不等待，第四个、第五个 user 也会因此而等待。在大并发情况下，让大家等待显得性能就太友好了。
所以，有些数据库这里引入了更新锁（如Mssql，注意：Mysql不存在更新锁）。
例7：-------------------------------------------------------------------------------------------------------------------------------------
T1:begin tran select * from table (加更新锁)update table set column1='hello'
T2:begin tran select * from table (加更新锁)update table set column1='world'
更新锁其实就可以看成排他锁的一种变形，只是它也允许其他人读（并且还允许加共享锁）。但不允许其他操作，除非我释放了更新锁。T1 执行 select，加更新锁。T2 运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。当后来有 user3、user4...需要查询 table 表中的数据时，并不会因为 T1 的 select 在执行就被阻塞，照样能查询，相比起例6，这提高了效率。
后面还有意向锁和计划锁：意向锁即是：某行修改时，自动加上了排他锁，同时会默认给该表加意向锁，表示里面有记录正被锁定，这时，其他人就不可以对该表加表锁了。如果没有意向锁这个类似指示灯的东西存在，其他人加表锁之前就得扫描全表，查看是否有记录正被锁定，效率低下。而计划锁这些，和程序员关系不大，就没去了解了。
四丶乐观锁和悲观锁的实现
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。（这点跟java中的synchronized很相似。）
2、在MySQL中如何实现悲观锁。？
mysql中有悲观锁的实现，我们想实现悲观锁时调用相对应得语句。
测试用表的结构和插入一行数据，下面其他的锁也会同时用到这个表。
use test;
create table msq_test (
id int primary key,
status char(4)5 ) engine = innodb default character set = 'utf8';
insert into msq_test(id, status) values(1, '1');操作：1、set autocommit=0; 2、select .....for update实现锁
注意：要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式：set autocommit=0;
//开始事务
begin;
//查询出主键id=1的信息
select status from t_goods where id=1 for update;
//修改status为2
update msq_test set status=2;
//提交事务
commit;注：上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交
在这里，我们使用了select…for update的方式，这样就通过数据库实现了悲观锁。此时在msq_test表中，id为1的 那条数据就被我们锁定了，其他事务的操作必须等待我们自己主动commit提交事务之后才能操作，这样我们可以保证当前的数据不会被其它事务修改。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制（添加版本号字段，这个字段和我们的业务无关）。
use test;
create table msq_test (
d int primary key,
status char(4)，
version not null
) engine = innodb default character set = 'utf8';
insert into msq_test(id, status，version) values(1, '1'，1);在上表中添加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
select * from msq_test where id =1;//得出一开始设置得version字段（versionValue）
update msq_test set status = newStatus,version = versionValue(老版本号) + 1 where version = versionValue;这样子就实现了乐观锁机制。