nicht angemeldet dedlfix
dedlfix
Matthias Apsel
TS
Rolf B
TS
TS
Hallo Forum,
ich habe eine sehr zeitfressende Query gefunden und verstehe grad gar nicht so recht, warum sie so zeitfressend ist.
Augeupdate mytable_uid set Status= 1 WHERE uid='".$ID."'
Benötigt bei ca. 400 Einträgen in der Tabelle zwischen 2 und 3 Sekunden. uid ist hierbei eine von php generierte unique ID.
Nach dem Setzen eines Indexes auf die Spalte uid benötigt die Query nur noch 0,1 Sekunden.
Warum hat sie vor der Indizierung aber so lange benötigt? Hängt das mit dem Inhalt zusammen? Benötigt eine varchar-Spalte wirklich so viel länger?
Pit
Tach!
update mytable_uid set Status= 1 WHERE uid='".$ID."'Benötigt bei ca. 400 Einträgen in der Tabelle zwischen 2 und 3 Sekunden.
Ja, so einen langsamen Datenbankserver hatte ich früher auch mal.
Aber Scherz beiseite, bei 400 Einträgen sollte das selbst ohne Index nicht so lange dauern.
Nach dem Setzen eines Indexes auf die Spalte uid benötigt die Query nur noch 0,1 Sekunden.
Warum hat sie vor der Indizierung aber so lange benötigt? Hängt das mit dem Inhalt zusammen? Benötigt eine varchar-Spalte wirklich so viel länger?
Generell kann man sagen, dass ohne Index ein Full Table Scan durchgeführt werden muss, um die zur Bedingung passenden Daten zu finden. Also jeder Datensatz muss angeschaut werden. Mit passendem Index kann die Suche nach den Kandidaten abgekürzt werden. Der Index liegt sortiert vor, und um in einer sortierte Menge etwas zu finden, gibt es recht schnelle Algorithmen.
Warum das allerdings bei dir so lange dauert, weiß ich nicht. Ergibt EXPLAIN irgendwas auffälliges?
dedlfix.
Hi dedlfix,
Benötigt bei ca. 400 Einträgen in der Tabelle zwischen 2 und 3 Sekunden.
Ja, so einen langsamen Datenbankserver hatte ich früher auch mal.
Danke, genau mein Humor :-/
Aber Scherz beiseite, bei 400 Einträgen sollte das selbst ohne Index nicht so lange dauern.
Tut es auch in einer Kopie der tabelle ohne Index im phpmyadmin nicht. Und da EXPLAIN auch so gar nichts auffälliges zeigt: Kann das sein, dass mysql einen cache hat und der irgendwie gegriffen hat? Ich habe nämlich die 400 Einträge nur übrig gelassen. Zuvor waren ca. 1,7 Mio. Einträge in der Tabelle, wovon ich bis auch die 400 alle anderen gelöscht habe.
Pit
Tach!
Tut es auch in einer Kopie der tabelle ohne Index im phpmyadmin nicht. Und da EXPLAIN auch so gar nichts auffälliges zeigt: Kann das sein, dass mysql einen cache hat und der irgendwie gegriffen hat? Ich habe nämlich die 400 Einträge nur übrig gelassen. Zuvor waren ca. 1,7 Mio. Einträge in der Tabelle, wovon ich bis auch die 400 alle anderen gelöscht habe.
Dann kann man sich das erklären mit der immer noch großen Datei und dass ein Suchen darin langsam ist. Nach dem Entfernen einer solchen großen Menge kann man mit Optimize Table die Dateigröße an die aktuellen Gegebenheiten anpassen. Gibts auch als Funktion im PMA.
dedlfix.
Hi dedlfix,
Dann kann man sich das erklären mit der immer noch großen Datei und dass ein Suchen darin langsam ist. Nach dem Entfernen einer solchen großen Menge kann man mit Optimize Table die Dateigröße an die aktuellen Gegebenheiten anpassen. Gibts auch als Funktion im PMA.
Ok, stimmt. Nach dem Optimieren benötigt die Query mit sowie ohne Index nur noch 0,11 Sek. Danke,
Pit
Nach dem Entfernen einer solchen großen Menge kann man mit Optimize Table die Dateigröße an die aktuellen Gegebenheiten anpassen.
Bitte auch diese Antwort von dedlfix für mich mal "plussen".
Hallo ursus contionabundo,
Bitte auch diese Antwort von dedlfix für mich mal "plussen".
Wenn du dich damals nicht eingeschnappterweise von diesem Forum abgewendet hättest, könntest du es locker selber tun.
Bis demnächst
Matthias
Hello,
Bitte auch diese Antwort von dedlfix für mich mal "plussen".
Wenn du dich damals nicht eingeschnappterweise von diesem Forum abgewendet hättest, könntest du es locker selber tun.
Könnt Ihr euch nicht mal im real Life zum Bier treffen und dort zanken?
Glück Auf
Tom vom Berg
Hallo TS,
Könnt Ihr euch nicht mal im real Life zum Bier treffen und dort zanken?
Interesse hätte ich schon … Warum zanken?
Bis demnächst
Matthias
Hallo Pit,
ja, das kann absolut sein. Du hast VARCHAR-Felder drin - guck mal hier, Punkt 3.
Mach einen OPTIMIZE TABLE auf die Table und schau dann mal, wie es ohne Index aussieht.
Rolf
Hallo Pit,
ja, das kann absolut sein. Du hast VARCHAR-Felder drin - guck mal hier, Punkt 3.
Mach einen OPTIMIZE TABLE auf die Table und schau dann mal, wie es ohne Index aussieht.
Hallo Rolf,
Ok, stimmt. Nach dem Optimieren benötigt die Query mit sowie ohne Index nur noch 0,11 Sek. Danke,
Pit
Offensichtlich ist der Server "sehr gut ausgelastet". Wäre die Tabelle mit den 400 Einträgen im Cache sähe das anders aus.
Benötigt eine varchar-Spalte wirklich so viel länger?
Äh? Eine Spalte "ID" enthält etwas anderes als BIGINT? Mit Verlaub ist das als "eher ungünstig" zu bezeichnen. Malen Finden nach Zahlen geht einfach schneller. Das ist aber nicht die Ursache der groben Verzögerung von 2 oder mehr Sekunden. (Wie wurde die denn gemessen?)
Hallo,
Äh? Eine Spalte "ID" enthält etwas anderes als BIGINT? Mit Verlaub ist das als "eher ungünstig" zu bezeichnen.
MalenFinden nach Zahlen geht einfach schneller. Das ist aber nicht die Ursache der groben Verzögerung von 2 oder mehr Sekunden. (Wie wurde die denn gemessen?)
Da es eine "uid" ist, kann ich keine BIGINT-Spalte nehmen. Es sind halt nicht nur Integer drin, sondern auch Strings.
Wie wurde die denn gemessen?
$query_update_uid="update mytable set Status= 1 WHERE myuid='".$ID."'";
$result_update_uid=mysqli_query($link,$query_update_uid);
$ende = microtime(true);
$laufzeit = round(($ende - $anfang),2);
$fp = fopen('log.txt', 'a+');
fwrite($fp,$laufzeit);
fclose($fp);
Pit
Da es eine "uid" ist, kann ich keine BIGINT-Spalte nehmen. Es sind halt nicht nur Integer drin, sondern auch Strings.
Aha. "uid" meint nicht "user-ide". Ungünstig. Aber womöglich meinst Du durch dashes separierte Gruppen heaxadezimal notierter Zahlen (UUID). Das sind also eigentlich keine Strings.
Literatur: Storing UUID Values in MySQL Tables
Da es eine "uid" ist, kann ich keine BIGINT-Spalte nehmen. Es sind halt nicht nur Integer drin, sondern auch Strings.
Aha. "uid" meint nicht "user-ide". Ungünstig. Aber womöglich meinst Du durch dashes separierte Gruppen heaxadezimal notierter Zahlen (UUID). Das sind also eigentlich keine Strings.
Literatur: Storing UUID Values in MySQL Tables
Danke für den Link, ich schaus mir mal an.
Pit
Hello,
Literatur: Storing UUID Values in MySQL Tables
Danke für den Link, ich schaus mir mal an.
Beachte auch dort den Hinweis auf "BINARY" :-)
Liebe Grüße
Tom S.
Hallo Tiradenbärchen,
verwechselst Du da nicht uid mit GUID?
Ich assoziiere mit uid sowas wie "Rolf B" oder "ursus contionabundo"
Rolf
Ich assoziiere mit uid sowas wie "Rolf B" oder "ursus contionabundo"
Namen sind dem Wesen nach nicht eineindeutig. IDs sollen es sein. Im Fall von "User Identifier" oder "Umsatzsteuer-Identifikationsnummer" oder "Unternehmens-Identifikationsnummer" oder "Unique Identifier" (alle mit UID abgekürzt) zwingend, im Fall von "UUID" nur "hinreichend eineindeutig".
Tiradenbärchen
Hehe. Die Übersetzung mit "Erklärbär" ist "klar erklärbarer".
Hallo Bärchen,
delivering a public speech or harangue
da war das englische Wiktionary wohl unvollständig. Aber Harangue ist eine Tirade oder Strafpredigt und passt gut zu dir 😀.
Rolf
Tirade, Strafpredigt
Naja. Auch ein Erklärbär darf mal brummen.
$ende = microtime(true); $laufzeit = round(($ende - $anfang),2);
Hm. Das ist die Laufzeit mindestens mit Request an den Datenbankserver und Antwort (sogar deren Auswertung), womöglich sogar mit Verbindungsaufbau. Möglicherweise also mit Netzwerk-hänger.
Leider kennt mysqli keine Methode oder Eigenschaft mit der man die Zeit auf dem Server selbst ausgeben kann.
Hello,
Da es eine "uid" ist, kann ich keine BIGINT-Spalte nehmen. Es sind halt nicht nur Integer drin, sondern auch Strings.
Ist bei der UUID nicht auch Groß-/Kleinschreibung relevant? Ich kann das leider im Moment nicht finden, ob der Wertebereich inzwischen erweitert wurde. PHP scheint ja auch nur Kleinbuchstaben zu verwenden. Ich bin mir aber sicher, dass ich schon Unique Identifier gesehen habe, die sowohl Groß- als auch Kleinbuchstaben verwenden.
[edit]:
Der Session Token bei PHP ist übrigens so ein Kandidat, der binary erfordern würde.
Dann MUSST Du auf jeden Fall einen Binary Typ nehmen, wie im anderen Thread schon erwähnt. Sonst könnte es irgendwann zu Kollisionen kommen mit UIDs in anderer Groß-/Kleinschreibweise aber denselben "Buchstaben".
Liebe Grüße
Tom S.
Tach!
Da es eine "uid" ist, kann ich keine BIGINT-Spalte nehmen. Es sind halt nicht nur Integer drin, sondern auch Strings.
Ist bei der UUID nicht auch Groß-/Kleinschreibung relevant?
Ob Pit bei uid UUID meint, ist noch nicht geklärt, aber gehen wir mal von UUID aka GUID aus. Wenn man die Stringrepräsentation nimmt, dann besteht natürlich die Möglichkeit, die Buchstabenanteile der Hex-Zahlen in groß oder klein zu schreiben. Ob das bei der Suche im DBMS relevant ist, hängt von der Kollation des Feldes ab.
Ich kann das leider im Moment nicht finden, ob der Wertebereich inzwischen erweitert wurde.
Der Wertebereich der einzelnen Teile der UUID steht fest, weil es Integer-Werte diverser Längen sind.
PHP scheint ja auch nur Kleinbuchstaben zu verwenden. Ich bin mir aber sicher, dass ich schon Unique Identifier gesehen habe, die sowohl Groß- als auch Kleinbuchstaben verwenden.
Das ist eine andere Baustelle und keine UUID/GUID. Meines Wissens hat PHP keine UUID/GUID-Unterstützung eingebaut.
Dann MUSST Du auf jeden Fall einen Binary Typ nehmen, wie im anderen Thread schon erwähnt. Sonst könnte es irgendwann zu Kollisionen kommen mit UIDs in anderer Groß-/Kleinschreibweise aber denselben "Buchstaben".
Die Binärdarstellung von UUIDs ist auch nicht eindeutig. Zum Beispiel hat .NET eine andere Auffassung als Java, an welcher Position welche Bytes der UUID zu liegen kommt.
dedlfix.
Ich kann das leider im Moment nicht finden, ob der Wertebereich inzwischen erweitert wurde.
Nein, ist er nicht. Auch UUID Version 4 und 5 halten sich an RFC 4122. In der String-Repräsentation(sic!) sind für die hex-Ziffern A bis F große und kleine Zeichen zulässig, haben aber (paarweise) die gleiche Bedeutung.
Hi,
Ob Pit bei uid UUID meint, ist noch nicht geklärt
php:
$pits_uid = uniqid(); 😉
Pit
Danke erstmal für die Klarstellung:
$pits_uid = uniqid();
Also etwas wie "5819f3ad1c0ce". Hoffentlich hast Du die Warnungen gelesen. Um sicher zu gehen solltest Du nämlich einen ausreichend großen Zufallswert "anhängen". Allerdings sind die Reserven dafür (maximal 9223372036854775807 / 4503599627370495 = 2048) klein, wie das schnelle Beispiel zeigt:
<?php
# echo "<pre>";
$uid = uniqid();
echo "UID: " . $uid . "\n";
echo "Max INT: " . PHP_INT_MAX . "\n";
echo "PHP max float: " . "99999999999999" ."\n";
echo "Max UUID: " . "fffffffffffff" . "\n";
echo "(hexdec) " . hexdec("fffffffffffff") ."\n";
echo "mysql max int: " . "4294967295" . "\n";
echo "UID.dec: " . hexdec($uid) . "\n";
echo "Reserve: " . PHP_INT_MAX / hexdec("fffffffffffff") . "\n";
Auf 32-Bit-Systemen geht das gar nicht vernünftig, da PHP_INT_MAX = 2147483647 und viel zu klein ist.
Aber allgemein gesagt kannst Du also hexdec benutzen und in MySQL den Datentyp BIGINT.
Falls Du (wegen der Warnungen) eine UUID willst.
CREATE TABLE table ( col binary(16) PRIMARY KEY );
INSERT INTO table ( col ) VALUES ( UUID_BIN( UUID() ) );
Anzeigbar Lesen:
SELECT BIN_UUD( col ) FROM table LIMIT 1;
Selektieren anhand UUID:
SELECT * FROM table WHERE col = UUID_BIN( "586bcc2d-9a96-11e6-852c-4439c456d444" );
Große Geheimnisse für PHP auf Linux:
<?php
if ( is_file ('/proc/sys/kernel/random/uuid') ) {
$UUID = file_get_contents('/proc/sys/kernel/random/uuid'); #hex
) else if ( is_file ( '/usr/bin/uuid' ) ) {
$UUID = `/usr/bin/uuid`; #hex
$UUID_BIN = `/usr/bin/uuid -F bin`; # binary!
$UUID_SIV = `/usr/bin/uuid -F siv`; # to long for real php-integer -> string
) else {
trigger_error( 'try to use a own funktion, eg: https://stackoverflow.com/questions/2040240/php-function-to-generate-v4-uuid', E_USER_ERROR );
}
Kassel, am 13. Oktober 2018, 13:11:
"Kleiner" Denkfehler: Die Reserve für einen Zufallswert beträgt
also 9218868437227405312
Die um einen nunmehr brauchbaren Zufallswert verbesserte numerische uid (nicht: uuid!) kann man also so bilden:
$betterUID = hexdec( uniqid( "", true ) ) +
+ random_int (
0 ,
( PHP_INT_MAX - hexdec( "fffffffffffff" )
)
);
Jetzt könnte man die Frage stellen, ob man nicht einfacher gleich:
$otherUID = random_int( 0, PHP_INT_MAX );
benutzt. Aber, jedenfalls jenseits der Warnungen zum zeitbasiertem uniqid() schließt eben die Methode mit uniqid() jedenfalls halbwegs gut eine Wiederholung aus, weil die Summe nicht kleiner werden kann als der zeitstempelbasierte Ansatz.
Bis das nicht mehr gilt vergehen wohl genug Jahre und bis dahin haben wir ganz andere Gültigkeitsbereiche.
Tach!
Danke erstmal für die Klarstellung:
$pits_uid = uniqid();Also etwas wie "5819f3ad1c0ce". Hoffentlich hast Du die Warnungen gelesen. Um sicher zu gehen …
… braucht es nur einen Unique Constraint auf dem Tabellenfeld, in dem sie eindeutig sein müssen.
dedlfix.
… braucht es nur einen Unique Constraint auf dem Tabellenfeld, in dem sie eindeutig sein müssen.
Ja. (Jemand sollte das "plussen".) Ist die scheinbar billigste Lösung.
Baden zu gehen war übrigens sehr erfrischend. Danach musste ich nunmehr an allen beiden meiner Fahrräder je einen Schlauch wechseln. Merke: Niemals mit zu geringen Luftdruck auf Schotterstrecken fahren.
Hallo
Falls Du (wegen der Warnungen) eine UUID willst.
- Bilde die UUID in MySQL, trage aber den binären Wert in die Datenbank ein. Spaltentyp ist row binary, Länge ist 16:
CREATE TABLE table ( col binary(16) PRIMARY KEY ); INSERT INTO table ( col ) VALUES ( UUID_BIN( UUID() ) );Anzeigbar Lesen:
SELECT BIN_UUD( col ) FROM table LIMIT 1;
Abgesehen davon, dass es im zweiten Codeblock vermutlich BIN_UUID( col ) und nicht BIN_UUD( col ) heißen soll, habe ich nirgendwo etwas über die Funktionen BIN_UUID und UUID_BIN finden können. MySQL kennt aber die Funktionen BIN_TO_UUID und UUID_TO_BIN, die allerdings erst mit Version 8.0 des Servers hinzugekommen sind.
Ich habe nach kurzer Recherche eine Seite mit äquivalenten Funktionen, die zum Backport nach MySQL 5.6 und 5.7 gedacht sind, gefunden. Ich kann die Qualität dieser Funktionen allerdings auf die Schnelle nicht beurteilen.
Tschö, Auge
Hello,
Das ist eine andere Baustelle und keine UUID/GUID. Meines Wissens hat PHP keine UUID/GUID-Unterstützung eingebaut.
Dann MUSST Du auf jeden Fall einen Binary Typ nehmen, wie im anderen Thread schon erwähnt. Sonst könnte es irgendwann zu Kollisionen kommen mit UIDs in anderer Groß-/Kleinschreibweise aber denselben "Buchstaben".
Die Binärdarstellung von UUIDs ist auch nicht eindeutig. Zum Beispiel hat .NET eine andere Auffassung als Java, an welcher Position welche Bytes der UUID zu liegen kommt.
Unabhängig vom Topic des Threads würde mich das näher interessieren. Kannst Du mit Lnks geben? Ich beschäftige mich gerade mit "Techniken für das Cloud-Computing". Da ist das ggf. relevant.
Glück Auf
Tom vom Berg
Tach!
Die Binärdarstellung von UUIDs ist auch nicht eindeutig. Zum Beispiel hat .NET eine andere Auffassung als Java, an welcher Position welche Bytes der UUID zu liegen kommt.
Unabhängig vom Topic des Threads würde mich das näher interessieren. Kannst Du mit Lnks geben? Ich beschäftige mich gerade mit "Techniken für das Cloud-Computing". Da ist das ggf. relevant.
Javas UUID hat keine Methode zur Ausgabe als Bytes, da kann man aber get[Least|Most]SignificantBits() nehmen. Zudem muss man noch wissen, mit welcher Endianess der Stream (z.B. Datei) erzeugt wurde.
dedlfix.
Hello,
Die Binärdarstellung von UUIDs ist auch nicht eindeutig. Zum Beispiel hat .NET eine andere Auffassung als Java, an welcher Position welche Bytes der UUID zu liegen kommt.
Unabhängig vom Topic des Threads würde mich das näher interessieren. Kannst Du mit Lnks geben? Ich beschäftige mich gerade mit "Techniken für das Cloud-Computing". Da ist das ggf. relevant.
Javas UUID hat keine Methode zur Ausgabe als Bytes, da kann man aber get[Least|Most]SignificantBits() nehmen. Zudem muss man noch wissen, mit welcher Endianess der Stream (z.B. Datei) erzeugt wurde.
ach du liebe Sch.....
Ich danke Dir! 😀
Kann man also noch nicht als verlässlichen und allgemeingültigen Standard hinstellen. Es gibt also noch keine wirklich einheitliche UUID.
Da gibt es wohl noch mehr ungeklärte Fälle beim Cloud-Computing. Wie geht man mit Datenbanken in öffentlichen Clouds bezüglich der Datensicherheit um? Gibt es inzwischen einen Ansatz für die Verschlüsselung?
Wirklich funktionieren tun die "sozialen Plattformen" (Facebook, Whatsapp, Twitter, ...) als Bestandteil des Cloud-Computing auch noch nicht. Alle (!) haben Lücken und keine Verlässlichkeit bezüglich des Datenschutzes. Einige mit eigenen Apps auf den Frontends (im Moment Whatsapp) gefährden über eine korrumpierbare Frontend-App sogar alle anderen sauber funktionierenden Dienste (sie können in deren Realm eindringen). Aber das ist schon wieder ein anderes Thema :-O
MMn stehen wir kurz vor dem Ende eines verlorenen Cyber-Wars! Dank Datensicherung könnte man sogar "Fünf Minuten nach Zwölf" noch etwas retten, aber dann müssten die deutschen Firmen und Politiker vielleicht endlich aufwachen!
Glück Auf
Tom vom Berg
Tach!
Es gibt also noch keine wirklich einheitliche UUID.
Doch, die UUIDs in ihrer lesbaren Darstellung.
dedlfix.
Hello,
Es gibt also noch keine wirklich einheitliche UUID.
Doch, die UUIDs in ihrer lesbaren Darstellung.
Sorry, da komme ich jetzt nicht mehr mit. Was sagen die Chinesen zu "lesbar". Oder meintest Du "Layer <X>" anstelle von "Layer 7"?
Wo sind die wie einheitlich lesbar?
Und wenn ich das richtig verstanden habe, sind sie auch nicht wirklich Global-Ein-Eindeutig?
Glück Auf
Tom vom Berg
Tach!
Es gibt also noch keine wirklich einheitliche UUID.
Doch, die UUIDs in ihrer lesbaren Darstellung.
Sorry, da komme ich jetzt nicht mehr mit. Was sagen die Chinesen zu "lesbar".
Chinesen kennen und verwenden die Ziffern 0 bis 9, und wer mit UUIDs in Berührung kommt, kann sicher auch a bis f, weil man als Programmierer die lateinische Schrift benötigt.
Wo sind die wie einheitlich lesbar?
Das Format ist definiert als xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx mit x = 0..1,a..f (inklusive Großbuchstaben).
Und wenn ich das richtig verstanden habe, sind sie auch nicht wirklich Global-Ein-Eindeutig?
Das ist richtig. Man hat das System aber schon so entworfen, dass die Wahrscheinlichkeit einer Kollision praktisch vernachlässigbar ist.
dedlfix.
Hello,
Äh? Eine Spalte "ID" enthält etwas anderes als BIGINT? Mit Verlaub ist das als "eher ungünstig" zu bezeichnen.
MalenFinden nach Zahlen geht einfach schneller. Das ist aber nicht die Ursache der groben Verzögerung von 2 oder mehr Sekunden. (Wie wurde die denn gemessen?)
Das ist aber ein Ammenmärchen. Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. Wenn man also Varbinary oder VarChar Binarynimmt, dann sollte da kein Laufzeitunterschied feststellbar sein.
Liebe Grüße
Tom S.
Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit.
"Bit ist Bit" mag in der allgemeinen Theorie gelten. Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss.
Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht:
Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt.
Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für ASCII gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung.
Dies gilt selbst bei (hier angezeigten, aber immer noch nicht sachgemäßen) Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen (allein die Kollation zu beachten zieht sehr viele, eigentlich unnötige Operationen nach sich) - ergo der erforderlichen Rechenzeit.
Fazit: Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nicht nur mehr lesen bzw. schreiben als unbedingt erforderlich ist und muss auch eigentlich unnötige Operationen (darunter für den optimalen Datentyp nicht angezeigte oder sogar unmögliche!) ausführen. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun.
Aber wie schon dargestellt: Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß.
Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.
Was meine Ausführungen übrigens bestätigt: Faktisch lag es ja an einer Speicherplatzverschwendung in gewaltigem Ausmaß.