Erfahren Sie mehr über Sperren in MySQL und sprechen Sie über Anwendungsszenarien!

Dieser Artikel wird Sie durch die Sperren in MySQL führen, gemeinsame Sperren, exklusive Sperren, pessimistische Sperren und optimistische Sperren verstehen und über Nutzungsszenarien sprechen. Ich hoffe, dass er für alle hilfreich ist!

1. Gängige Sperrtypen

• Sperre auf Tabellenebene, Sperre die gesamte Tabelle
• Sperre auf Seitenebene, sperrt eine Seite
• Sperre auf Zeilenebene, sperrt eine Zeile
• Gemeinsame Sperre, auch S-Sperre genannt. In MyISAM wird sie auch als Lesesperre bezeichnet Arten von Engines in MySQL, unter denen InnoDB- und MyISAM-Engines die am häufigsten verwendeten sind
• 3. Unterschiede zwischen häufig verwendeten Engines
• MyISAM verwendet Tabellensperren, um Daten zu verwalten. Wenn Sie einen Datensatz aktualisieren, müssen Sie die gesamte Tabelle sperren, was dazu führt, dass die Leistung gering und die Parallelität nicht hoch ist. Natürlich wird es gleichzeitig kein Deadlock-Problem geben.

Die größten Unterschiede zwischen InnoDB und MyISAM sind zwei Punkte: Erstens unterstützt InnoDB Transaktionen; zweitens verwendet InnoDB Sperren auf Zeilenebene.

In MySQL sperren Sperren auf Zeilenebene nicht direkt Datensätze, sondern sperren Indizes. Indizes werden in Primärschlüsselindizes und Nicht-Primärschlüsselindizes unterteilt. Wenn eine SQL-Anweisung mit dem Primärschlüsselindex arbeitet, sperrt MySQL den Primärschlüsselindex Nicht-Primärschlüsselindex und sperren Sie ihn dann.

InnoDB-Zeilensperre wird durch Sperren von Indexeinträgen erreicht. Wenn kein Index vorhanden ist, sperrt InnoDB Datensätze über einen versteckten Clustered-Index. Mit anderen Worten: Wenn Sie Daten nicht über Indexbedingungen abrufen, sperrt InnoDB alle Daten in der Tabelle, und der tatsächliche Effekt ist der gleiche wie beim Sperren einer Tabelle. Da kein Index vorhanden ist, müssen Sie die gesamte Tabelle durchsuchen, um einen bestimmten Datensatz zu finden. Um die gesamte Tabelle zu durchsuchen, müssen Sie die Tabelle sperren.

• 4. Gemeinsame Sperren und exklusive Sperren

Standardmäßig werden exklusive Sperren zum Hinzufügen, Löschen und Ändern von Datenbanken hinzugefügt, während Abfragen keine Sperren hinzufügen.

• Gemeinsame Sperre:

  Fügen Sie einer bestimmten Ressource eine gemeinsame Sperre hinzu. Sie können die Ressource lesen, und andere können die Ressource auch lesen (Sie können auch weiterhin gemeinsame Sperren hinzufügen, dh mehrere gemeinsam genutzte Sperren können nebeneinander existieren). , aber Sie können nicht überarbeiten. Wenn Sie es ändern möchten, müssen Sie warten, bis alle gemeinsamen Sperren aufgehoben sind.

• Exklusive Sperre:
Fügen Sie einer bestimmten Ressource eine exklusive Sperre hinzu. Sie können sie hinzufügen, löschen, ändern und überprüfen, andere können jedoch keine Vorgänge ausführen.

//共享锁
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视频教程】

Das obige ist der detaillierte Inhalt vonErfahren Sie mehr über Sperren in MySQL und sprechen Sie über Anwendungsszenarien!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!