MySQL并发控制

无论何时，只要有多个查询需要在同一时刻修改数据，就会存在并发控制的问题。

MySQL在这两个层面上就进行了并发控制，分别是服务器层和存储引擎层。

下面举一个简单的例子，在发送邮件的时候，可能单条邮件发送很正常，不会出什么问题，仅仅是一条接着一条这样来实现发送，但是在并发环境下，却不会是想象中的那么简单。

假设这样一种可能，有两个进程同时对同一个邮箱来投递邮件，会发生什么情况呢？

显然，邮箱中的数据会被破坏，两封邮件可能同时并且交叉的将邮件附加在邮箱的末尾，这样就会出现只收到一份邮件的数据错读的情况。针对这种情况，我们可以选择在邮箱上加锁，来防止是数据被破坏。加入客户试图投递邮件，但是此时邮箱已经被其他用户锁住，那么此时前者需要等待，直到后者释放锁资源才能够进行发送。

加锁虽然解决了多进程导致数据错失的问题，但是并不能解决高并发的情况，因为此时对系统加锁，那么意味着在同一时刻只能由一个进程来对邮箱进行操作，而其他的用户必须一直等待，这在大容量的邮箱中是一个巨大的问题

读写锁

从邮箱中读取数据没有这么的麻烦，因为针对读数据来说，即使在同一个时刻有多个用户对数据进行并发读取，那也是不会对数据造成什么大的伤害。但是假设考虑这么一种情况，在某个用户正在读数据的同时，另外一个用户正在对编号为1的邮件进行删除的操作，那会出现什么后果？

结论是不确定，有可能正在读取的用户会因为其他用户删除邮件的操作而导致报错退出，有可能会读取到前后不一致的数据，那么此时对于读操作来说，也是具有一定的风险的。所以，为了安全起见，读操作也要特别注意。

那么我们现在将上述的邮箱看成一张表，将邮箱中的邮件看成一行又一行的记录，又会出现什么情况呢？

很容易看出，此时在数据库以及数据库的表中，进行上述的高并发读写的操作，也会出现读写错误的情况，那么此时MySQL针对这种情况也进行了相对应的控制。

在处理并发读或者写的时候，可以实现一个由两种类型组合而成的锁系统来解决问题，这种锁系统通常称为共享锁和排他锁，也成为读锁和写锁。

这两种锁的概念如下：

读锁是共享的，或者说是互不影响、互不阻塞的，可以实现多个用户在读取同一个用户时不出现互相干扰的情况。

写锁是互斥的，也就是说一个写锁会阻塞其他进程的写锁和读锁，这是处于安全策略的考虑。

大多数的时候，MySQL的内部管理系统是透明的，也就是针对程序员来说是处于一种不可见的状态。

锁粒度

另外一种提高共享资源并发性的方法就是实现锁粒度的操作，也就是让锁锁定的对象更具有针对性，有选择性，尽量只锁定需要修改的部分的数据，而不是所有的资源。

在给定的数据量上，锁的数据量越少，系统的并发程度就越高，只要相互之间不会造成影响即可。

加锁会造成系统资源的消耗，锁的一系列操作，比如加锁、解锁、检查锁等都会造成给系统开销的增大，如果系统花费大量的时间来管理锁，而不是用来管理资源，那么系统的性能就会大大降低。

所谓的锁的策略，就是在系统实现的锁的开销和数据的安全性之间寻找平衡，当然加了锁，多多少少会影响到一点性能的问题。

MySQL提供了多种的选择，每个MySQL引擎都可以实现自己的锁策略和锁粒度。下面介绍两种最重要的锁策略：

表级锁

表锁是MySQL中最基本的策略，并且是开销最小的策略。例如上面的邮箱的例子，MySQL表锁就是针对整个“邮箱”进行加锁，在用户对表进行写操作的时候（插入、删除、更新）都会先获取锁，然后对整张表进行锁定的操作，这样对于其他的用户来说就会阻塞所有该表的读取、写入的操作。只有在没有写锁的情况下，其他读取的用户才能获得该锁，读锁与读锁之间是不会互相阻塞的。

另外，写锁比读锁有更高的优先级。假设在同一时刻进行读、写的操作，那么写锁是可以直接插入到读锁的前面的（但是，读锁就不能插入到写锁的前面）

行级锁

行级锁可以最大程度地支持并发操作（但是同时也带来了最大的系统开销），行级锁只在存储引擎层实现，在MySQL的服务器层面是没有实现的（也就是说MySQL服务器完全不了解存储引擎中行级锁的实现）。