Lösen Sie das Problem der Selbstinkrementierung des int-Primärschlüssels von MySQL

Einführung

Wenn wir die MySQL-Datenbank verwenden, sind wir es gewohnt, int als Primärschlüssel zu verwenden und ihn auf Auto-Inkrement einzustellen. Dies kann Eindeutigkeit gewährleisten und ist bequem zu verwenden. Die Länge des int-Typs ist jedoch begrenzt. Was passiert, wenn die Länge überschritten wird?

Das Problem aufdecken

Lassen Sie uns zunächst eine Testtabelle erstellen. Die Erstellungsanweisung lautet wie folgt:

CREATE TABLE test1 (
  Ich würde INT PRIMARY KEY AUTO_INCREMENT,
  NAME VARCHAR(20)
)

Dann fügen wir zwei Daten ein:

INSERT INTO test1 VALUES(NULL,'Kalb');
INSERT INTO test1 VALUES(NULL,'Wert');

Die Abfragetabelle zeigt normalerweise Folgendes an:

Der Bereich des Typs „signed int“ beträgt 231 -1 = 2147483647. Wir fügen Daten mit der ID 2147483647 direkt wie folgt ein:

INSERT INTO test1 VALUES(2147483647 ,'Xiaohua')

Die Ergebnisse zeigen normal:

An diesem Punkt hat die Auto-Increment-ID die Obergrenze des int-Typs erreicht. Wenn ich weitere Daten einfüge, wird ein Fehler gemeldet:

INSERT INTO test1 VALUES(NULL,'Kuh');

Zu diesem Zeitpunkt kann der Primärschlüssel nicht mehr erhöht werden und die eingefügte ID ist immer noch 2147483647, was die eindeutige Bedingung des Primärschlüssels verletzt, sodass ein Fehler gemeldet wird.

Lösung des Problems

(1) Verwenden Sie einen größeren Datentyp, Bigint

Der Bereich von Bigint beträgt 263-1, die sogenannte exponentielle Explosion. Die Größe erreicht zu diesem Zeitpunkt die schreckliche Größenordnung von 9.223.372.036.854.775.807. Einfach ausgedrückt: Wenn Sie Bigint verwenden, um 1 Million Daten pro Tag zu speichern, dauert es 20 Milliarden Jahre, bis es explodiert. Im aktuellen Szenario besteht also fast kein Grund zur Sorge über die automatische Inkrementierung von Bigint.

Wir ändern den Datentyp in Bigint, wie in der Abbildung gezeigt

Führen Sie dann die Insert-Anweisung aus:

INSERT INTO test1 VALUES(NULL,'Kuh');

Kann wieder normal einfügen:

(2) Verwenden Sie UUID als Primärschlüssel

Wir alle wissen, dass die UUID auf der Grundlage einer Reihe von Parametern wie der aktuellen Systemleistung und dem Zeitstempel berechnet wird, um eine weltweit eindeutige Zeichenfolge zu erhalten. MySQL bietet eine Methode zum Generieren der UUID. Die Verwendung als Primärschlüssel kann die Eindeutigkeit der Daten sicherstellen.

Der folgende Code kann zum Generieren einer 32-Bit-UUID verwendet werden:

-- 32-Bit-UUID generieren
Wählen Sie Ersetzen (UUID (), '-', ') als UUID;

Dann erstellen wir eine Testtabelle:

CREATE TABLE test2(
  id VARCHAR(50) Primärschlüssel,
  NAME VARCHAR(20) NICHT NULL
)

Fügen Sie ein Datenelement ein:

-- UUID einfügen
INSERT INTO test2 VALUES(REPLACE(UUID(),'-',''),'Ausführen');

Es scheint jedoch etwas zu mühsam, die UUID-Funktion jedes Mal manuell zu schreiben, wenn Sie eine Insert-Anweisung schreiben. Wir können einen Trigger schreiben, der die ID automatisch für uns festlegt:

-- Trigger erstellen DELIMITER $$
ERSTELLEN
TRIGGER auto_id -- Name BEFORE INSERT -- Triggerzeit ON test2 FOR EACH ROW -- wirkt auf die Tabelle test2 und wird auf jede Datenzeile angewendet BEGIN
WENN new.id = '' DANN -- UUID festlegen, wenn die ID eine leere Zeichenfolge ist
  SETZEN Sie neue.id = REPLACE(UUID(),'-','');
ENDE, WENN;
ENDE$$

Fügen Sie ein Datenelement ein:

-- Fügen Sie Daten ein INSERT INTO test2 VALUES('','Xiao Wang');

Das Ergebnis kann normal addiert werden

Zusammenfassen

(1) Die Typen int und bigInt lassen sich schneller hinzufügen, löschen, ändern und abfragen als UUID und sparen mehr Platz.

(2) Die Verwendung von UUID ist bequemer.

Warum Auto-Increment-Int als Primärschlüssel verwenden?

Ich glaube, jeder weiß, dass Sie als Datentyp des Primärschlüssels „unsigned auto-incrementing int“ verwenden sollten, aber wissen Sie, warum Sie „auto-incrementing int“ anstelle von „varchar“, „text“, „varchar“ und anderen Typen verwenden sollten?

Jeder kann auch einige Vorteile nennen: transparent für das übergeordnete Geschäft, keine explizite Angabe beim Einfügen von Daten erforderlich, einfache Datentypen, einfacher zu speichernde und zu verwaltende Tabellenstruktur

Tatsächlich bietet die Verwendung von Auto-Increment-Int als Primärschlüssel viele Vorteile. Lassen Sie uns heute mehr darüber erfahren und Ihnen dringend empfehlen, Auto-Increment-Int in der tatsächlichen Entwicklung als Primärschlüssel zu verwenden.

Vorteil:

1. Int benötigt weniger Speicherplatz als varchar, char und text und verfügt über einen einfachen Datentyp, der CPU-Overhead spart und die Verwaltung der Tabellenstruktur erleichtert.

2. Standardmäßig wird ein Primärschlüsselindex für den Primärschlüssel erstellt. Die Verwendung einer Ganzzahl als Primärschlüssel kann mehr Indizes in den Speicher laden und die Abfrageleistung verbessern

3. Bei der InnoDB-Speicher-Engine verwendet jeder Sekundärindex den Primärschlüssel als Suffix des Indexwerts. Die Verwendung eines automatisch inkrementierenden Primärschlüssels kann die Länge (Größe) des Indexes verringern und das Laden weiterer Indexdaten in den Speicher erleichtern.

4. Es kann Indexdaten kompakter machen. Beim Einfügen, Löschen und Aktualisieren von Daten kann es Seiten mit Indexdaten so wenig wie möglich verschieben und aufteilen, die Generierung von Fragmenten reduzieren (Sie können die Tabelle durch Tabellenoptimierung neu erstellen) und die Wartungskosten senken.

5. Beim Einfügen von Daten kann sichergestellt werden, dass logisch benachbarte Elemente auch physisch benachbart sind, was für die Bereichssuche praktisch ist

Natürlich hat die Verwendung eines automatisch inkrementierenden int als Primärschlüssel auch ihre Nachteile. In Situationen mit hoher Parallelität kann es außerdem zu Sperrkonflikten kommen.

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.