mysql（并发控制，读写锁，锁粒度）

并发控制:

只要有多个查询需要在同一时间修改数据，都会产生并发控制的问题，解决方式可以通过lock锁来防止数据破坏，数据在本次连接修改时被锁了起来，下次修改必须等待本次修改完成才可以修改，也就是直到锁释放之后，虽然这样工作良好但是并不支持并发处理，因为在任意一个时刻，只有一个进程可以修改数据`、 `同一时刻多个用户并发读取也不会出现问题，这是因为读取不会修改数据，如果一个客户读取数据，而另一个用户正在删除数据这时候结果就不确定了，可能报错，也可能读取到不一样的数据，为了安全即便时读取也需要注意

读写锁:

读写锁
同一时刻多个用户读取不会出现问题，因为读取不会修改数据
使用并发控制可以解决这类问题，在处理并发读写时可以通过由两种类型的锁组成的所系统来解决这样的问题，
共享锁（shared lock）(读锁 read lock)
读锁是共享的，时互相不阻塞，索格客户端可以同一时刻取同时读取一个资源，互不干扰
排他锁（exclusive lock)(写锁 write lock)
一个写锁会阻塞其他的写锁和读锁，处于安全，只有这样才能保证在给定的时间里只有一个用户能执行写入，并防止其他用户读取正在写入的同一个资源

锁粒度

锁粒度：
锁粒度时一种提高共享资源并发性的方式，是让锁定对象更有选择性，尽量只锁定需要修改的部分数据，而不是所有的资源，只对修改的数据片进行精确的锁定任何时候，在给定的资源上，锁定的数据量越少，则系统的并发成都越高，只要互相不发生冲突即可
锁的各种操作，包括获得锁，检查锁是否已经解除，释放锁等，都会增加系统的消耗，如果系统花大量的时间来管理锁，而不是存取数据，那么系统的可能性就会受到影响
锁策略就是在锁的开销和数据的安全性之间寻求平衡，一般都是在表上施加行级锁(row-level lock) 并以复杂方式进行实现，以便在锁比较多的情况下尽可能提供更好的性能
mysql存储引擎都可以实现自己的锁策略和锁粒度，在存储引擎的设计中锁管理是非常重要的决定，将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，同时也会失去另一些应用场景的良好支持
mysql有多个存储引擎，每个引擎都有不同的特点和应用场景

表锁（table lock）
表锁时开销最小的，表锁会锁定整张表，一个用户在对标进行写，插入，删除，更新等操作前，需要先获取到写锁，这会阻塞其他用户对该表的所有读写操作，只有没有写锁时，其他用户才可以获得读锁，读锁之间时不相互阻塞的
表锁支持某些类型的并发写操作，另外写锁也比读锁有更高优先级，一个械所请求可能会插入到读锁队列的前面，读锁不可以插到写锁的前面，服务器会为例如alter table之类的语句使用表锁，而忽略存储引擎锁机制
#################################################################################

行级锁(row lock)
行级锁可以最大程度支持并发处理，同时开销也是最大的锁开销，在innoDB ，XtraDB 实现了行级锁，行级锁旨在存储引擎层实现，而服务层没有实现，服务层完全不了解存储引擎中锁的实现，所有的存储引擎都以自己的方式实现了锁的机制