mysql锁

一、并发控制
无论何时，只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。并发控制是一个内容庞大的话题。关于解决并发问题，都是从服务器层高与存储引擎层进行控制的。设计良好的邮箱投递系统会通过锁机制来防止数据损坏。如果客户视图投递邮件，而邮箱已经被其他客户锁住，那就必须等待，直到释放锁才能进行投递。这种方式并不支持并发处理，因为任意一个时刻，只有一个进程可以修改邮箱的数据，这在大容量的邮箱系统中是个问题。

二、读写锁
数据库系统在处理并发读或者写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题，这两种类型的锁通常被称之为共享锁（读锁）和排他锁（写锁）。
这里不讨论数据库系统具体实现，主要了解锁的概念：读锁是共享的，或者说是互相不阻塞的。多个客户端在同一时刻可以同时读取同一个资源，而互不干扰。写锁是排他的，也就是说一个写锁会阻塞其他的读锁和写锁，这是出于数据安全考虑，确保在给定的时间内，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。
在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，mysql会通过锁定防止其他用户读取同一数据。

三、锁粒度
为提高共享资源的并发性就需要让锁定对象更有选择性，尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。锁定的资源数据量越小，系统的并发性就越高，只要锁相互之间不发生冲突即可。
问题是加锁也需要消耗系统资源。锁的各种操作，包括获得锁，检查锁是否已经解除，释放锁等，都会增加系统的开销。如果系统话费大量的时间来管理锁，而不是存取数据，那么系统的整体性能可能会受到影响。所以，需要在锁的开销和数据的安全性之间寻求一个平衡。
mysql提供了多种选择。每种mysql的存储引擎都可以实现自己的锁策略和锁粒度。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，但是同时也会失去另外一些应用场景的良好支持，好在mysql支持多个存储引擎的架构，所以不需要单一的通用解决方案。

四、两种最重要的锁策略，表锁和行锁

表锁：表锁是mysql中的最基本锁策略，并且是开销最小的策略。它会锁住整张表。当一个用户对表进行写操作（插入、删除、更新等）前，需要先获得写锁，这时就会阻止其他用户对该表的所有的读和写操作。只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。
写锁比读锁有更高的优先级，因此用户的写锁请求可能会被插入到读锁队列的前面（写锁可以插入到锁队列中读锁的前面，反之读锁则不能插入到写锁的前面）

行级锁：行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。行级锁只在存储引擎层实现，而mysql的服务器层没有实现。服务器层完全不了解存储引擎层的实现。所有的存储引擎都以自己的方式显现了锁机制。

五、死锁
死锁是指两个或者多个事物操作在同一资源上相互占用，并请求对方占用的资源，从而导致恶性循环的现象。
比如：第一个事物：先修改A行数据，再去修改B行数据，那么第一个事物会，先锁定A数据，更改数据后，接着去获得B行数据的写锁。
第二个事物：刚好相反，先修改B行数据，在修改A行数据，那么第二个事物会先锁定B数据行，更改数据后，接着去获取A行数据的写锁。
那么问题就来了，第一个事物需要获得B行写锁，完成操作才能释放第二个事物需要的A行写锁。而第二个事物占用着B行写锁，并需要第一个事物占用的A行写锁来完成操做。这两个数据行的锁被两个事物互相占用，彼此没有完成操做又无法释放对方需要的锁。死锁是由于既定规则造成的，那么就需要外部因素介入才能解除死锁。
数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。
对于事务型的系统，死锁是无法避免面的，大多数情况下只需要重新执行因死锁回滚的事物即可。