所有的锁都是解决资源竞争，数据同步问题
锁模式分类 乐观，悲观锁
范围锁 行锁，表锁
算法锁 临间锁，间隙锁，记录锁
属性锁 共享锁，排他锁
状态锁 意向共享锁，意向排他锁
乐观锁
{
乐观锁(非sql自带)：认为每次操作(更新)都不会冲突，每次操作的时候插入一个flags(按照一定规律变化)
每次操作的时候先取出这个flags，检查这个flags有没有变化，有的话正在操作修改的会回滚
适用场景：乐观并发控制多数用于数据争用不大、冲突较少的环境中
不足：乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，
直到提交的时候才去锁定，所以不会产生任何锁和死锁，但如果两个事物同时读取sql某一行，经过读写回sql,
这就有问题了
}
悲观锁
{
悲观锁(sql自带)：类似Cpp的互斥锁(跟乐观锁相对，认为没催操作都会出现数据冲突)，进行资源操作的时候先获取锁，
如果获取到锁才能进行对应的数据操作，获取不到则进行数据操作
适用场景：悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中
不足：效率比较低，可能存在死锁，只读类型事务处理之中不存在冲突不必要加锁，降低并行性
}
共享锁
{
共享锁(sql自带)：属于悲观锁的一种，当上锁之后其他事物只能对数据进行读锁，不能写锁。
}
排它锁
{
排他锁(sql自带)：属于悲观锁的一种，当上锁之后其他事物不能对数据进行读锁，写锁。
}
行锁
{
行锁：
优缺点： 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低, 并发度也最高
适用于高并发环境下，对事务完整性要求较高的系统，如在线事务处理系统
}
婊子锁
{
婊子锁：
优缺点：开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；锁定粒度大，发生锁冲突的概率最高,并发度最低
适用与并发性不高，以查询为主，少量更新的应用，比如小型的web应用
}
页锁
{
fuck:
https://zhuanlan.zhihu.com/p/52678870
https://blog.csdn.net/puhaiyang/article/details/72284702