Hallo

da ich nicht sicher sagen kann, ob das _immer_ so funktioniert oder einfach nur Glück war, belasse ich es mal bei einem Screenshot

Ich hatte das beim Suche nach dem Fehler auch irgendwo gelesen, finde es aber nicht mehr.

Ich habe mittlerweile selbst Zeit gefunden, zu suchen. ROW_FORMAT = DYNAMIC wird als ein Weg vorgeschlagen, das Problem zu lösen [1]. Ein anderer Vorschlag ist es, die MySQL-Konfigurationsdatei mit innodb_large_prefix = 1 beziehungsweise als Abfrage mit SET GLOBAL innodb_large_prefix = `ON` in Kombination mit set SET GLOBAL innodb_file_format = BARRACUDA anzupassen, womit ein Index bis zu 3072 Bytes groß werden kann. Dieser Weg fällt für uns aus, da die Forenbetreiber wohl nur in Ausnahmen Zugriff auf die Serverkonfiguration haben dürften (sowohl auf die Datei als auch in Sachen Datenbankrechte).

In diesem Stack-Overflow-Thread ist für mich die aktuell letzte Antwort, beginnend mit "This is an XY problem" interessant. Der Autor beleuchtet das Problem von einer anderen Seite, nach der sich die bei dir angegebene Fehlermeldung auf ein Symptom bezieht und nicht auf die Ursache.

Danach ist das Problem, dass der UNIQUE-Index die Vermeidung doppelter Einträge sicherstellen soll und die Feldgröße unterschiedlich lange Einträge ermöglicht, von denen die längsten die maximal mögliche Größe eines Index-Eintrags sprengen können.

Der Vorschlag ist nun, für jeden Eintrag einen Hash (der Autor schlägt SHA256 vor) mitzuführen. Ein Hash hat immer die gleiche Länge. Ein Hash braucht keinen Charset utf8mb4, er braucht nicht einmal utf8, denn er besteht nur aus ASCII-Zeichen, die, so schlägt der Autor vor, per UNHEX als 32-Bit-Bynary-Feld gespeichert werden sollen. Ein Index auf das Hash-Feld kann die maximale Größe des Index-Eintrags nicht sprengen, womit sich das Ausgangsproblem in Wohlgefallen auflöst.

In seinem Beispiel geht es um E-Mail-Adressen, die zur Speicherung mit UNHEX(SHA2(email, 256)) behandelt werden.

- UNHEX: MySQL-Doku, eingeführt: ?, laut Doku verfügbar mit MySQL 5.5
- SHA2: MySQL-Doku, eingeführt: ?, laut Doku verfügbar mit MySQL 5.5, Achtung: "This function works only if MySQL has been configured with SSL support." Keine Ahnung, ob wir das voraussetzen können.

Da wir den Wert des Tags nicht kryptografisch verschleiern wollen – er steht schließlich im Klartext eine Spalte "neben" dem Hash –, könnte auch SHA1 reichen. Allerdings wurden für SHA1 schon Kollisionen (verschiedene Zeichenketten, für die mit SHA1 der selbe Hash errechnet wird) nachgewiesen.

Ob diese Lösung für uns überhaupt gangbar ist, müssen wir testen.

Tschö, Auge

[1]: Github, Gitea-Issue zur Fehlermeldung 1709; Stack-Overflow-Thread zur Fehlermeldung 1709