Dies müsste wirklich gemessen werden, wir können einige "Vermutungen" anstellen, basierend auf dem, was wir wissen und was wir annehmen, aber das sind nur Vermutungen.
Sie erwähnen nicht, ob diese Tabelle InnoDB oder MyISAM mit dynamischen Zeilen oder MyISAM mit Zeilen fester Länge ist. Das wird einen Unterschied machen.
Aber für Werte wie den, den Sie gepostet haben, '961637593864109_412954765521130' (31 Zeichen), vorausgesetzt, Sie verwenden einen Einzelbyte-Zeichensatz (z. B. latin1) oder einen Zeichensatz, der diese bestimmten Zeichen in ein einzelnes Byte codiert (z. B. utf8) ...
Für das dynamische InnoDB- und MyISAM-Format sind das 31+1-8=24 zusätzliche Bytes für diese Zeile. (BIGINT passt in 8 Bytes, ein VARCHAR(31)-Wert von 31 Zeichen verwendet 32 Bytes.)
Für eine MyISAM-Tabelle mit Zeilen fester Länge wäre das eine Differenz von 23 Bytes pro Zeile. (Platz ist für alle 31 Zeichen reserviert, und die Länge muss nicht gespeichert werden.)
Dieser Primärschlüsselwert wird auch in jedem Index wiederholt, sodass mit jedem Index auch mehr Platz zur Verfügung steht.
Unter der Annahme, dass Ihre Tabellenzeilen bei BIGINT 120 Bytes groß sind und die Zeilen bei VARCHAR 144 Bytes groß sind, sind das 20 % Zunahme. Je größer Ihre Zeilen, desto kleiner der prozentuale Anstieg und umgekehrt.
Für 1.000.000 Zeilen (ich möchte "eine meelyun Zeilen" so sagen, wie Dr. Evil seinen kleinen Finger an den Mundwinkel legt und "eine Million Dollar" sagt) ergeben diese zusätzlichen 24 Bytes pro Zeile ungefähr 24 MB.
Aber es ist nicht wirklich so einfach. In Bezug auf den InnoDB-Speicherplatz geht es darum, wie viele Zeilen in einen Block „passen“. Je größer die durchschnittliche Zeilengröße, desto größer ist der freie Speicherplatz in einem Block.
Wenn Sie nichts mit den Zeilen machen, außer sie auf der Festplatte zu speichern, dann ist es wirklich nur eine Erhöhung des Festplattenspeichers und zusätzliche Zeit und Speicherplatz für Backups.
Wenn die gleiche Anzahl von "144-Byte"-Zeilen in einen Block passt wie "120-Byte"-Zeilen, dann werden Sie keinen Unterschied im Raum sehen. Aber wenn weniger Zeilen in einen Block passen, bedeutet das mehr Blöcke, mehr Platz im InnoDB-Pufferpool, mehr I/O usw.
Bei Abfragen einer einzelnen Zeile, entweder nach dem Primärschlüsselwert oder nach einer anderen eindeutigen Indexsuche, ist der Unterschied vernachlässigbar.
Wenn Sie es mit größeren Ergebnismengen zu tun haben, dann ist das zusätzlicher Speicher zum Vorbereiten der Ergebnismenge und zusätzliche Bytes zum Übertragen an den Client usw.
Wenn der VARCHAR-Schlüssel so konzipiert ist, dass "Gruppen" von Zeilen, auf die zusammen zugegriffen wird, denselben führenden Teil des Schlüsselwerts haben, kann es mit InnoDB tatsächlich zu einer Leistungsverbesserung kommen. Das liegt daran, dass der Primärschlüssel der Clusterschlüssel ist ... viel bessere Chancen, dass die Zeilen, die zum Erfüllen einer Abfrage benötigt werden, sich im selben Block befinden, anstatt über eine Reihe von Blöcken verteilt zu sein.
Das Gegenteil ist, wenn Einfügungen und Löschungen durchgeführt werden, gibt es mehr freien Speicherplatz in einigen Blöcken. (Bei den Löschungen bleibt der Platz für gelöschte Zeilen im Block; um diesen wiederzuverwenden, müssten Sie eine Zeile einfügen, die denselben Schlüsselwert hatte (oder zumindest einen Schlüsselwert, der nahe genug beieinander liegt, dass er im selben Block landet .) Und mit zufälligen Einfügungen erhalten wir Blockaufteilungen.
