Specified key was too long

[Timbalu]

Ich update gerade eine mysql4 auf eine mysql5 datenbank.

Bei einigen Tabellen kommt immer dieser Fehler #1071

Code: Select all

CREATE TABLE `s_permalinks` (
  `permalink` varchar(255) NOT NULL default '',
  `entry_id` int(10) unsigned NOT NULL default '0',
  `type` varchar(200) NOT NULL default '',
  `data` text,
  KEY `pl_idx` (`permalink`),
  KEY `ple_idx` (`entry_id`),
  KEY `plt_idx` (`type`),
  KEY `plcomb_idx` (`permalink`,`type`)
) TYPE=MyISAM;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes

SQL-Befehl:

CREATE TABLE `s_plugincategories` (
`class_name` varchar( 250 ) default NULL ,
`category` varchar( 250 ) default NULL ,
KEY `plugincat_idx` ( `class_name` , `category` )
) TYPE = MYISAM ;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes 

nehme ich die doppelten keys raus oder reduziere sie auf einen, geht es.
Wie ist nun die beste Vorgehensweise?
(KEY `plcomb_idx` (`permalink`,`type`) habe ich ganz weggelassen und KEY `plugincat_idx` ( `class_name` , `category` ) auf KEY `plugincat_idx` ( `class_name` ) reduziert.)

[garvinhicking]

Hi!

Ja, das ist ne frickelige Sache. In neuen s9y Versionen sind die Index-Längen in der db.sql angepasst um das Problem zu vermeiden.

Seit MySQL5 benutzt die Datenbank für UTF-8 Indexe immer 3 Bytes statt 2 Bytes. Da die maximale Keylänge bei 1000 Zeichen liegt darf somit die allozierte Zeichenlänge 333 Zeichen nicht überschreiten.

D.h. die Summe aller Indexschluüssellängen muss unter 333 liegen, man muss den KEY-Teil der SQL-Queries so anpassen dass man bei den langen Spalten die Länge einschränkt:

Code: Select all

  KEY `plcomb_idx` (`permalink`(200),`type`(133))

Grüße,
Garvin

[Timbalu]

Aih.... Danke für die Info.

Dann in etwa so?

Code: Select all

CREATE INDEX plcomb_idx ON s9y_permalinks (`permalink`(200),`type`(133));
CREATE INDEX plugincat_idx ON s9y_plugincategories (`class_name`(180),`category`(153));

Edit:
Ja das ging ohne Probleme!

[Timbalu]

In neuen s9y Versionen sind die Index-Längen in der db.sql angepasst um das Problem zu vermeiden.

Aha, dann war wohl mein Fehler erst die mysql4 Datenbank auf die neueste Serendipity Version abzudaten und dann auf mysql5 zu wechseln, oder?

Allerdings habe ich bei einer Suche im sql Ordner nichts gefunden was diese beiden KEYs anging.
db.sql von 1.6Alpha3
CREATE INDEX plcomb_idx ON {PREFIX}permalinks (permalink, type);
CREATE INDEX plugincat_idx ON {PREFIX}plugincategories(class_name, category);
allerdings auch keine anderen CREATE INDEX mit solcherart Formulierung, weder im db.sql, noch in irgendwelchen updates oberhalb von 0.6, nur im update 1.1Alpha5 auf -6 gibt es so etwas ähnliches....
@ALTER TABLE {PREFIX}exits ADD PRIMARY KEY (entry_id, day , host(64), path(64));

Bist du dir also sicher mit dieser Aussage?
Abgesehen davon, dass es ja jetzt gut damit funktioniert.

Oder meintest du damit die varchar Länge? Im Falle des permalinks tables sind die beiden, später mit dem Doppel Index versehenen, Spalten 255 und 200 lang, also mehr als 333 ...

Edit:
(Server Version: 5.1.37, MySQL-Client-Version: mysqlnd 5.0.8-dev - 20102224)
Ich habe gerade mal nachgesehen ... in mindestens 4 meiner localen serendipty Installationen habe ich beide KEYs überhaupt gar nicht, was mir nie aufgefallen wäre, wenn ich nicht dieses völlig unabhängige Upgrade einer anderen DB gehabt hätte. Woran liegt das?
Könnte das jemand anderes bei sich auch noch mal prüfen?

Ich habe im Übrigen schon immer leicht den Verdacht gehabt, dass nicht wirklich alle db updates etc up2date sind.... (auch bei manchen plugins...) - deshalb:
Gibt es so etwas wie einen db integrity check der alle tabellen spalten keys etc einer vorhandenen Installation mit der db.sql abgleicht und eventuell sogar repariert?

[garvinhicking]

Hi!

Einige der Keys stehen nur in der db.sql, das kann sein. Das waren dann aber meist nur nicht soo relevante Keys, für die ich den aufwand einer eigenen DB-Update gescheut habe.

Einen Integrity-Check gibt es nicht, ich glaube das kann man auch automatisiert nicht so gut machen, da man ja die db.sql dafür erstmal auswerten und in ein verwertbares Format bringen müsste....das is schon Aufwand.

Grüße,
Garvin

[Timbalu]

Einige der Keys stehen nur in der db.sql, das kann sein. Das waren dann aber meist nur nicht soo relevante Keys, für die ich den aufwand einer eigenen DB-Update gescheut habe.

Verstehe, das ist in diesen beiden Fällen aber nicht so ... ich sehe da auch nix von dieser Beschränkung auf 333...

Code: Select all

Search "plcomb_idx" (4 hits in 4 files)
  \serendipity\sql\db.sql (1 hits)
	Line 287: CREATE INDEX plcomb_idx ON {PREFIX}permalinks (permalink, type);
  \serendipity\sql\db_update_0.9-alpha1_0.9-alpha2_mysql.sql (1 hits)
	Line 11: CREATE INDEX plcomb_idx ON {PREFIX}permalinks (permalink, type);
Search "plugincat_idx" (2 hits in 2 files)
  \serendipity\sql\db.sql (1 hits)
	Line 294: CREATE INDEX plugincat_idx ON {PREFIX}plugincategories(class_name, category);
  \serendipity\sql\db_update_0.9-alpha3_0.9-alpha4_mysql.sql (1 hits)
	Line 6: CREATE INDEX plugincat_idx ON {PREFIX}plugincategories(class_name, category);

Einen Integrity-Check gibt es nicht, ich glaube das kann man auch automatisiert nicht so gut machen, da man ja die db.sql dafür erstmal auswerten und in ein verwertbares Format bringen müsste....das is schon Aufwand.

Nun ja, man muss das ja nicht sooo machen...

Ein einziges Mal ordentlich manuell gemacht, könnte man dieses Serendipity als db_check_mysql.sql (dito für die anderen Datenbanken) file mitgeben und bräuchte das nur dann ergänzen, wenn sich irgendwann mal wieder in der db.sql etwas ändern sollte, was ja seit den neueren Versionen ziemlich selten ist.

Wenn man dann eine geeignete Struktur oder Indezes query über die bereits vorhandene db laufen lässt, sollte man doch relativ einfach vergleichen und zumindestens eine Information über fehlende Indizes erstellen können. Die Frage ist natürlich ob das so viel bringt, dass sich die Mühe lohnt...

[garvinhicking]

Hi!

Der Index muss nicht zwangsläufig "plcomb_idx" heißen, evtl heißt der auch mal anders; die Namen sind ja beliebig...

Ein einziges Mal ordentlich manuell gemacht, könnte man dieses Serendipity als db_check_mysql.sql (dito für die anderen Datenbanken) file mitgeben und bräuchte das nur dann ergänzen, wenn sich irgendwann mal wieder in der db.sql etwas ändern sollte, was ja seit den neueren Versionen ziemlich selten ist.

Jo, daher scheue ich den Aufwand auch noch etwas solange größere DB-Updates nicht in Sicht sind...

Grüße,
Garvin

[Timbalu]

Jo, daher scheue ich den Aufwand auch noch etwas solange größere DB-Updates nicht in Sicht sind...

Hi Garvin
Dabei geht es doch gerade um nicht korrekt "geALTERterte" Serendipity DBs, die schon mehrere Updates hinter sich haben... Ich wäre ja eventuell bereit daran mitzuwirken und das vielleicht sogar in das verify plugin zu übernehmen... aber nur, wenn das auch wirklich Sinn macht..!