Apprenez-en plus sur les verrous dans Mysql et discutez des scénarios d'utilisation !

Cet article vous fera découvrir les verrous dans Mysql, comprendra les verrous partagés, les verrous exclusifs, les verrous pessimistes, les verrous optimistes et parlera des scénarios d'utilisation. J'espère qu'il sera utile à tout le monde ! 1. Types de verrouillage courants appelé verrou S, il est également appelé verrou de lecture dans MyISAM

Verrou exclusif, également appelé

Types de verrous courants

• 2. Introduction au moteur MySQL
• En fait, il existe de nombreux types de moteurs dans MySQL, parmi lesquels les moteurs InnoDB et MyISAM sont les plus couramment utilisés
• Le moteur MyISAM était utilisé par défaut avant la version mysql5.5, puis utilisez le moteur InnoDB
• pour afficher les commandes du moteur de base de données comme suit

• show variables like '%storage_engine%';

3. Différences entre les moteurs couramment utilisés

MyISAM utilise des verrous de table pour gérer les données. Si vous mettez à jour un enregistrement, vous devez verrouiller la table entière, ce qui entraîne des performances faibles et une concurrence peu élevée. Bien entendu, il n’y aura pas de problème de blocage en même temps.

Les plus grandes différences entre InnoDB et MyISAM sont deux points : premièrement, InnoDB prend en charge les transactions ; deuxièmement, InnoDB utilise des verrous au niveau des lignes.

Dans Mysql, les verrous au niveau des lignes ne verrouillent pas directement les enregistrements, mais verrouillent les index. Les index sont divisés en index de clé primaire et index de clé non primaire. Si une instruction SQL opère sur l'index de clé primaire, MySQL verrouillera l'index de clé primaire. Si une instruction opère sur un index de clé non primaire, MySQL verrouillera d'abord l'index de clé primaire. index de clé non primaire, puis verrouillez-le. Index de clé primaire associé.
• Le verrouillage des lignes InnoDB est obtenu en verrouillant les entrées d'index S'il n'y a pas d'index, InnoDB verrouillera les enregistrements via un index cluster caché. En d'autres termes : si vous ne récupérez pas de données via les conditions d'indexation, InnoDB verrouillera toutes les données de la table, et l'effet réel est le même que le verrouillage de la table. Puisqu'il n'y a pas d'index, vous devez analyser la table entière pour trouver un certain enregistrement. Pour analyser la table entière, vous devez verrouiller la table.

4. Verrous partagés et verrous exclusifs

• Par défaut, des verrous exclusifs seront ajoutés aux ajouts, suppressions et modifications de la base de données, tandis que les requêtes n'ajouteront aucun verrou.

• Verrou partagé :
Ajoutez un verrou partagé à une certaine ressource. Vous pouvez lire la ressource, et d'autres peuvent également lire la ressource (vous pouvez également continuer à ajouter des verrous partagés, c'est-à-dire que plusieurs verrous partagés peuvent coexister). , mais vous ne pouvez pas réviser. Si vous souhaitez le modifier, vous devez attendre que tous les verrous partagés soient libérés.
• Verrou exclusif :

  Ajoutez un verrou exclusif à une certaine ressource. Vous pouvez ajouter, supprimer, modifier et vérifier, mais les autres ne peuvent effectuer aucune opération.

//共享锁
select * from 表名 lock in share mode

//排他锁
select * from 表名 for update

五、排他锁的实际应用

• 这里我们以两个操作数据库的请求为例，假设这两个请求分别为T1和T2
• 假设T1为查询请求，而T2为更新数据请求，在T1查询很长时间的时候，还没有返回结果，但是这时候T2过来请求更新了
• 这个流程应该是: T1运行加共享锁、T2运行、发现T1未完成等待其完成、T1完成、T2开始执行
• T2之所以要等待，是因为T2执行更新的时候需要给表加排他锁，但是数据库规定，不能在同一资源上同时共存这两种锁，所以T2必须等T1执行完，释放锁后，才可以正常操作

T1: select * from 表名 lock in share mode //假设还未返回结果

T2: update 表名 set name='autofelix'

六、共享锁的实际应用

• 如果T1和T2都是执行的查询，也就是都加共享锁
• 这时候就不用等待，可以立马执行
• 因为同一资源上可以同时存在多个共享锁，也被称为，共享锁与共享锁兼容
• 意味着共享锁不阻止其他人同时读取资源，但是阻止其他人修改资源

T1: select * from table lock in share mode

T2: select * from table lock in share mode

七、死锁的发生

• 假设T1和T2都同时执行2个资源操作，分别是查询和更新数据
• 假设T1和T2同时达到select，T1对表加共享锁，而T2也加上了共享锁
• 当T1的select执行完毕，准备执行update时
• 根据锁机制，T1的共享锁必须升级到排他锁才可以执行接下来的update操作
• 在升级排他锁之前，必须等T2的共享锁释放，同理，T2也在等T1的共享锁释放
• 于是都在等待对方的锁释放，导致程序卡死，这种情况就是死锁

T1: 开启事务,执行查询更新两个操作

     select * from table lock in share mode

     update table set column1='hello'

T2: 开启事务,执行查询更新两个操作

     select * from table lock in share mode

     update table set column1='world'

八、另一种发生死锁的情景

•  当T1和T2都是只执行更新语句的时候
• 如下程序所示，这种语句非常的常见，很多人觉得他会产生死锁，其实要看情况
• 如果id是主键，由于主键机制，并不需要全表扫描，直接可以更新当前数据，所以不会产生死锁
• 如果id是普通字段，那么当T1加上排他锁之后，T2为了找到id=20条数据，必须进行全表扫描，当他扫到第10条的时候，发现这里有排他锁，导致全表扫描进行不下去，就会导致等待

T1: begin
     update table set content='hello' where id=10

T2: begin
     update table set content='world' where id=20

九、死锁的解决方式

• 就是让T1和T2顺序执行，比如T1在执行完select后，立马给自身加上排他锁，这样T2不得不等待T1执行完才能继续
• 但是如果有很多请求过来的话，都必须等待，这对用户特别的不友好
• 所以，某些数据库引入了另一种方式，叫做更新锁，这里mysql除外，不存在更新锁
• 更新锁其实就是排他锁的另一种实现，只是他允许其他人读的同时加共享锁，但是不允许其他操作，除非释放了更新锁
• 流程大概如此: T1执行完select加上更新锁，T2执行查询完，准备加更新锁，发现已经有了，就等待，其他请求过来，如果查询是不受影响的，但是更新才等待
• 这相比上面的查询也要等待增加了效率

T1: begin

     select * from table for update

     update table set content='hello'

T2: begin

     select * from table for update

     update table set content='world'

T1: begin

     select * from table [加更新锁操作]

     update table set content='hello'

T2: begin

     select * from table [加更新锁操作]

     update table set content='world'

十、意向锁和计划锁

• 计划锁与程序猿无关，不需要了解
• 意向锁，Innodb特有，分为意向共享锁和意向排他锁
• 意向共享锁: 表示事务获取共享锁时，必须先得获取该表的意向共享锁
• 意向排他锁: 表示事务获取排他锁时，必须先得获取该表的意向排他锁
• 我们知道要对整个表加锁，必须保证表内不存在任何锁
• 如果一行行的去检查是否加锁，效率必然极低，这时候可以检测意向锁是否被占用即可

十一、乐观锁和悲观锁

• 乐观锁和悲观锁都是针对select而言的
• 比如在商品抢购中，用户购买后库存需要减1，而很多用户同时购买时，读出来的库存数量一样，然后多个用户同时用该库存去减1
• 这种做法必然会出现很大的漏洞，如果向在淘宝，京东出现这种情况，你就可以打包回家种地了
• 这种情况如何解决呢，其实可以使用悲观锁进行解决，说白了也就是排他锁
• 用户进来查库存的时候，就加上排他锁，等他所有操作完成后，再释放排他锁，让其他人进来
• 不让用户等待，就可以使用乐观锁方式解决，乐观锁一般靠表的设计和时间戳来实现
• 一般是在表中添加version或者timestamp时间戳字段
• 这样就会保证如果更新失败，就表示有其他程序更新了数据库，就可以通过重试解决

update table set num=num-1 where id=10 and version=12

【相关推荐：mysql视频教程】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!