Was ist der Unterschied zwischen optimistischem Sperren und pessimistischem Sperren in MySQL?

Unterschied: Pessimistisches Sperren ist eine pessimistische Haltung gegenüber der Datenverarbeitung und geht immer davon aus, dass beim Erfassen und Ändern von Daten Parallelitätskonflikte auftreten und die Daten daher während des gesamten Datenverarbeitungsprozesses gesperrt werden müssen. Optimistic Locking ist hinsichtlich der Datenverarbeitung optimistisch und geht davon aus, dass es im Allgemeinen nicht zu Konflikten kommt. Nur wenn Datenaktualisierungen übermittelt werden, werden Datenkonflikte erkannt.

Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.

Pessimistisches Sperren und optimistisches Sperren sind von Menschen definierte Konzepte. Sie können sie als Idee und gemeinsame Methode für den Umgang mit gleichzeitigen Ressourcen verstehen.

Verwechseln Sie sie nicht mit den in MySQL bereitgestellten Sperrmechanismen (Tabellensperren, Zeilensperren, exklusive Sperren, gemeinsam genutzte Sperren).

1. Pessimistische Sperre

Wie der Name schon sagt, handelt es sich um eine pessimistische Haltung gegenüber der Datenverarbeitung. Es wird immer davon ausgegangen, dass es beim Abrufen und Ändern von Daten zu Parallelitätskonflikten kommt. Daher müssen die Daten während des gesamten Datenverarbeitungsprozesses gesperrt werden.

Die Implementierung pessimistischer Sperren basiert normalerweise auf dem von der Datenbank bereitgestellten Sperrmechanismus, z. B. der exklusiven Sperre von MySQL. Wählen Sie ... zum Aktualisieren aus, um pessimistische Sperren zu implementieren.

Beispiel: Während des Produkt-Flash-Sales wird die Lagermenge reduziert, um Überverkaufssituationen zu vermeiden.

CREATE TABLE `tb_goods_stock` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `goods_id` bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
  `nums` int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `modify_time` datetime DEFAULT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `goods_id` (`goods_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';

Setzen Sie den Feldtyp „Produktbestandsmengennummern“ auf „Unsigned“, um sicherzustellen, dass auf Datenbankebene keine negativen Zahlen auftreten.

Beachten Sie, dass Sie zur Verwendung pessimistischer Sperren die Autocommit-Funktion von MySQL deaktivieren und Autocommit = 0 festlegen müssen.

Beachten Sie, dass die Sperren auf Zeilenebene in MySQL auf Indizes basieren. Ebenensperren werden verwendet. Die gesamte Tabelle ist gesperrt.

1. Öffnen Sie die Transaktion, fragen Sie die zu verkaufenden Waren ab und sperren Sie den Datensatz.

begin;select nums from tb_goods_stock where goods_id = {$goods_id} for update;

2. Stellen Sie fest, ob die Menge des Produkts größer als die Kaufmenge ist. Wenn Sie nicht zufrieden sind, setzen Sie die Transaktion zurück.

3. Wenn die Bedingungen erfüllt sind, reduzieren Sie den Lagerbestand und reichen Sie die Transaktion ein.

update tb_goods_stock set nums = nums - {$num} where goods_id = {$goods_id} and nums >= {$num};
commit;

Wenn die Transaktion festgeschrieben wird, wird die Sperre während der Transaktion aufgehoben.

Pessimistische Sperren verfolgen eine konservative Strategie, bei der die Daten zuerst gesperrt und dann in der Parallelitätskontrolle verarbeitet werden. Dies gewährleistet zwar die Sicherheit der Datenverarbeitung, verringert jedoch auch die Effizienz.

2. Optimistische Sperre

Wie der Name schon sagt, ist es optimistisch, dass Daten unter normalen Umständen nicht in Konflikt geraten .

Wenn ein Konflikt festgestellt wird, wird eine Fehlermeldung an den Benutzer zurückgegeben, sodass der Benutzer entscheiden kann, wie vorgegangen werden soll.

Die Implementierung der optimistischen Sperre basiert nicht auf dem von der Datenbank bereitgestellten Sperrmechanismus. Die Implementierungsmethode besteht im Allgemeinen darin, die Datenversion aufzuzeichnen, und die andere erfolgt über die Zeitstempel.

Fügen Sie der Tabelle ein Versionsnummern- oder Zeitstempelfeld hinzu. Lesen Sie die Versionsnummer zusammen. Wenn die Daten aktualisiert werden, addieren Sie 1 zur Versionsnummer.

Wenn wir das Datenupdate einreichen, stellen wir fest, ob die aktuelle Versionsnummer mit der zuerst gelesenen Versionsnummer übereinstimmt. Wenn sie gleich sind, aktualisieren Sie sie. Andernfalls gelten die Daten als abgelaufen, die Aktualisierung wird abgelehnt und der Benutzer wird zur erneuten Operation aufgefordert.

CREATE TABLE `tb_goods_stock` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `goods_id` bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
  `nums` int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `modify_time` datetime DEFAULT NULL COMMENT '更新时间',
  `version` bigint(20) unsigned DEFAULT '0' COMMENT '版本号',
  PRIMARY KEY (`id`),
  UNIQUE KEY `goods_id` (`goods_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';

1. Überprüfen Sie das zum Verkauf stehende Produkt und erfahren Sie die Versionsnummer.

begin;select nums, version from tb_goods_stock where goods_id = {$goods_id};

2. Stellen Sie fest, ob die Menge des Produkts größer als die Kaufmenge ist. Wenn Sie nicht zufrieden sind, setzen Sie die Transaktion zurück.

3. Wenn die Bedingungen erfüllt sind, reduzieren Sie den Lagerbestand. (Stellen Sie beim Aktualisieren fest, ob die aktuelle Version mit der in Schritt 1 erhaltenen Version übereinstimmt.)

update tb_goods_stock set nums = nums - {$num}, version = version + 1 where goods_id = {$goods_id} and version = {$version} and nums >= {$num};

4. Stellen Sie fest, ob der Aktualisierungsvorgang erfolgreich ausgeführt wurde, andernfalls führen Sie einen Rollback durch.

Optimistisches Sperren basiert auf der Programmimplementierung, sodass es keinen Deadlock gibt und für Anwendungsszenarien mit vielen Lesevorgängen geeignet ist. Treten häufig Konflikte auf, erfordert die Anwendung der oberen Ebene weiterhin eine erneute Bedienung durch den Benutzer, was tatsächlich zu einer Leistungseinbuße führt. In diesem Fall ist eine pessimistische Sperre besser geeignet.

(Empfohlenes Tutorial:

MySQL-Video-Tutorial)

Das obige ist der detaillierte Inhalt vonWas ist der Unterschied zwischen optimistischem Sperren und pessimistischem Sperren in MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!