并发控制
并发控制:当多个连接对记录进行修改的时保证数据的一致性。
悲观锁，乐观锁
确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和一致性以及数据库的统一性，乐观锁和悲观锁是并发控制主要采用的技术手段。
- 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
- 在查询完数据的时候就把事务锁起来，直到提交事务
- 实现方式：使用数据库中的锁机制
- 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
- 在修改数据的时候把事务锁起来，通过version的方式来进行锁定
- 实现方式：使用version版本或者时间戳
悲观锁的两种实现
image
悲观锁应用场景
悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。
锁的力度 [锁的颗粒]
锁的颗粒: 锁定时的单位
其实只需要对修改的数据精确加锁即可。而无需对所有的资源都加锁。
比如一个用户表一个商品表，当用户修改注册信息的时候只需要对用户表或者用户这条记录加锁即可而不需要对商品表加锁。
同理用户在更新商品信息的时候，只需要对商品表或者商品表中的这一记录进行加锁即可而不需要对用户表也加锁。
所以说：加锁只加最对的而不加最大的。加锁会增加系统的开销
所以，我们需要在[锁策略，锁开销，数据安全之间]寻求一种平衡
锁策略
MySQL的锁策略包括两种
- 表锁:开销最小的锁的策略。
- 原因：如果存在一张表，把所有用户锁定起来，那么这张表只有一个用户可以操作。
- 行锁:开销最大的锁的策略。也是支持最大并发操作处理的一种情况
- 原因：表中有多少条记录，就可能对这张表的每条记录都进行锁。所以是开销最大的
当用户针对数据表操作时用户即获得了这种表的写锁的权限。写锁会禁止其他用户来进行读写的操作。
优劣
乐观锁
乐观锁可能会在CAS情况中出现ABA问题。、
悲观锁
悲观锁在处理并发控制上的态度其实是先取锁再访问。在并发情况下为数据的安全提供了保障，但是带来的是性能上的影响。在处理被加锁的数据上无疑会带来额外的开销，降低了并行性，还有可能产生死锁(事物控制不好)。而且只读型事物不会产生并发冲突，也就不需要用锁，这样做只会增加系统的负载。
实现
乐观锁
select * from user where id = #{id}
update from user set username = #{username},version = #{version} + 1 where id = #{id} and version = #{version};
已经知道该记录在没有发生并发冲突情况下的version了。只是不确定是否发生了并发冲突,所以拿该值过来检测，记录需要满足的条件和该版本号一致。
悲观锁
select * from user where id = #{id} for update;
update from user usernmae = #{username} where id = #{id}
MySQL中InnoDB引擎的行锁是通过加在什么上完成
InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,
如果 id 不是索引键那么InnoDB将完成表锁,并发将无从谈起
