加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。
锁包括行级锁和表级锁、页级锁
行级锁
是一种排他锁，防止其他事务修改此行；行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁。
特点
开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页级锁
页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折中的页级，一次锁定相邻的一组记录。BDB支持页级锁。
特点
开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
表级锁
锁定粒度大，发生锁冲突的概率最高,并发度最低。
特点
开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；
平时会经常看到或者听到数据库锁有“共享锁”，“排它锁”，“互斥锁”，“写锁”，“读锁”，“悲观锁”，“乐观锁”，“行级锁”，“表级锁”，“页级锁”等，同时我们还会常看到“丢失修改“，”不可重复读“，”读脏数据“这三个术语，他们究竟是什么关系以及怎么理解呢，下面就来介绍一下他们。
先说事务的特性，要想成为事务，必须满足：ACID（原子性，一致性，隔离性，持久性）四特性，事务是恢复和并发控制的基本单位。
1.原子性指的是事务是数据库的逻辑工作单位，事务中操作要么都做，要么都不做；
2.一致性指的是事务的执行结果必须是使数据库从一个一致性状态变为另一个一致性状态，一致性和原子性是密切相关的；
3.隔离性指的是一个事务执行不能被其他事务干扰；
4.持久性指的是一个事务一旦提交，他对数据库中数据的改变就是永久性的。
表级锁又分为5类：
行共享(ROWSHARE)——禁止排他锁定表；
行排他(ROWEXCLUSIVE)——禁止使用排他锁和共享锁；
共享锁(SHARE)——锁定表，对记录只读不写，多个用户可以同时在同一个表上应用此锁；
共享行排他(SHAREROWEXCLUSIVE)——比共享锁更多的限制，禁止使用共享锁及更高的锁；
排他(EXCLUSIVE)——限制最强的表锁，仅允许其他用户查询该表的行。禁止修改和锁定表；
共享锁(S锁）和排它锁（X锁）是具体的锁，是数据库机制上的锁，存在以下关系：
（x表示是排它锁(Exclusive)，s表示共享锁(Share)，Y表示yes，N表示no）
上图表示可以共存的锁，如，第二行表示，一个事务T1给某数据加了X锁，则事务T2就不能再给那数据加X锁了，同时也不能再加S锁了，只有到T1事务提交完成之后，才可以。默认来说，当sql脚本修改更新某条记录的时候，会给该条记录加X3锁，读的话加的是S锁。
上图表示可以共存的锁，如，第二行表示，一个事务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，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防，预防的方法有：
①一次封锁发，指的是一次性把所需要的数据全部封锁住，但是这样会扩大了封锁的范围，降低系统的并发度；
②顺序封锁发，指的是事先对数据对象指定一个封锁顺序，要对数据进行封锁，只能按照规定的顺序来封锁，但是这个一般不大可能的。
另外，系统如何判断出现死锁呢，毕竟出现死锁不能一直干等下去，要及时发现死锁同时尽快解决出现的死锁，诊断和判断死锁有两种方法，
一是超时法，超时法就是如果某个事物的等待时间超过指定时限，则判定为出现死锁；
二是等待图法。等待图法指的是如果事务等待图中出现了回路，则判断出现了死锁。
对于解决死锁的方法，只能是撤销一个处理死锁代价最小的事务，释放此事务持有的所有锁，同时对撤销的事务所执行的数据修改操作必须加以恢复
何谓悲观锁与乐观锁
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
两种锁的使用场景
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
乐观锁常见的两种实现方式
乐观锁一般会使用版本号机制或CAS算法实现。
1.版本号机制
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加1。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
举一个简单的例子：假设数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段（balance）为$。
操作员A此时将其读出（version=1），并从其帐户余额中扣除50（50=（-50））。在操作员A操作的过程中，操作员B也读入此用户信息（version=1），并从其帐户余额中扣除20（80=（-20））。操作员A完成了修改工作，将数据版本号加1（version=2），连同帐户扣除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。操作员B完成了操作，也将版本号加1（version=2）试图向数据库提交数据（balance=$80），但此时比对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略，因此，操作员B的提交被驳回。
这样，就避免了操作员B用基于version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。
2.CAS算法