对Mysql锁的理解

在我实际的开发过程中，对mysql的锁考虑得并不多。如果遇到并发的问题，第一个想到的可能是用redis的原子性来解决，并不会去考虑实际业务场景下的用户数是否多到必须要用redis。网上已经有很多关于mysql锁的类型、隔离级别等的讲解了，这里主要分享一些想法，如果你觉得不对，欢迎指出。

1. mysql加锁并不依赖事务，比如就单条update语句而言，因为其本身已经具备原子性，所以就不再需要事务来保证原子性了。因此可以想象当并发更新同一条记录时，它的执行是串行的，并不会出现多条update语句同时对一条记录进行更新。但串行并不意味着更新的顺序是正确的，更新的数据是正确的，在实际的业务场景中为了保证数据的正确性，串行往往是不够的。
2. 然而有些加锁却是需要依赖事务的，比如select .... for update（当然还有其它的sql语句，这里主要讲我工作中遇到的），如果要对筛选出来的数据加锁，需要提前开启事务，这点需要注意。
3. 在并发量不大，但对数据正确性有较高要求的情况下，比如有些2B的应用，没有必要使用redis，用mysql锁就可以了，但这往往在实际的开发过程中被忽略。
4. 锁与索引的关系，最常用的InooDB引擎，虽然说是行级锁，但也要是在用对的情况下，如果sql语句无法命中索引，可能导致表级锁，降低整体并发性能，这里又一次突出索引的重要性。（之所以说“又一次”，是因为在最近的项目中，遇到企图用redis来解决mysql索引设计不合理所造成的慢的问题）
5. 关于乐观锁，用乐观锁的目的在于锁的粒度小，加锁和释放锁非常快，可以支持较高的并发。
6. 不建议在事务中使用乐观锁，在事务中执行 基于“数据版本记录机制“（实现乐观锁的一种方式）的 update语句后，锁并不会立刻释放，需要等待事务提交或者回滚，而在这个过程中，其它线程对这些记录的更新操作是会被阻塞的，锁的粒度变大，导致并发降低，这与使用乐观锁的初衷相违背。然而在实际的开发过程中，为了保证数据的一致性，又不得不使用事务，我遇到的就是在对记录进行更新前，直接就用悲观锁对记录进行锁定，以此保证并发情况下数据的正确性。乐观锁的使用还是要看业务场景，不能为了用而用。

 

本文地址：https://blog.csdn.net/zhongzhen7355/article/details/107392742