YeSoft - innovate IT Il Blog di YeSoft sul mondo ICT

Le sorprese di MySQL…

http://blog.yesoft.it/wp-content/plugins/sociofluid/images/digg_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/reddit_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/stumbleupon_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/delicious_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/furl_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/technorati_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/google_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/myspace_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/facebook_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/yahoobuzz_48.png http://blog.yesoft.it/wp-content/plugins/sociofluid/images/twitter_48.png
MySQL: a volte ti sorprende!

MySQL: a volte ti sorprende!

Ogni giorno c’è una novità. A volte è positiva ma, spesso, se ne incontrano di curiose o addirittura “odiose”!

E’ stato durante un test di un applicativo che stiamo sviluppando che, studiando i log, ci siamo imbattuti in un “carinissimo” errore del DBMS (MySQL v.5.1).

Chi usa MySQL non può non affezionarsi al suo meraviglioso modo di “dettagliare” a fondo gli errori, soprattutto quelli sintattici. Praticamente, ogni volta è una vera e propria caccia al tesoro! Sono infatti entusiasta quando sono di fronte ad un problema perché c’è davvero da mettersi alla prova!

Scherzi a parte, oggi MySQL mi ha risposto (e sembrava abbastanza arrabbiato e stizzito!) con un errore STUPENDO:

Got error 139 from storage engine

A dir poco fantastico! La prima cosa che ho pensato è stata: “Questa è musica non quella Tiziano Ferro!”.

[Ok, avevo detto scherzi a parte...]

Insomma, l’errore spiega tutto: “C’è l’errore 139 dall’engine di memorizzazione”. Bastava aggiungerci: “Solo se sei un cretino non capisci cos’è!”.

Per fortuna, in rete se ne parla a sufficienza. Cito la spiegazione da un articolo delle FAQ di tol.it (http://faq.tol.it/article.php?id=571):

L’errore riguarda il motore InnoDB di MySQL.
La dimensione massima di una singola riga di MySQL e’ 8000 bytes, esclusi ovviamente i campi Varchar, Blob, e Text.
La dimensione massima di una riga che contiene anche campi Varchar, Blob e Text e’ di 4GB.
Le colonne che contengono campi LongBLOB e LongText non posso eccedere i 4GB ciascuna e non sono inclusi nel computo del valore di 8000 bytes.
Il problema nasce dal fatto che InnoDB memorizza sempre i primi 768 bytes di ciascun campo Varchar, Blob e Text nella riga stessa ( e il resto in memoria separata).
Pertanto avendo piu’ di 11 campi text si eccede la dimensione massima di 8000 bytes, dato che sono comunque memorizzati 768 bytes per ciascun campo.
La soluzione consiste nello spezzare la tabella in piu’ tabelle mantendosi sotto il valore di 11 campi text/varchar/blob ovvero sotto il valore:
768*11=8448 .
Questa impostazione e’ presente dalla versione di MySQL 4.1 per ragioni di compatibilita’ con altri database.

Altre fonti sembrano trattarlo proprio come bug ma a me sembra soltanto un’enorme limitazione! Avevo infatti 2 tabelle che contenevano, tra gli altri, 12 campi di tipo TEXT e ho dovuto splittarle. Sembra, infatti, che non ci sia altra soluzione.

E tutto ciò, per mantenere una “compatibilità con altri database”?

Quest’ultima cosa mi sembra davvero fantasiosa… ma non avendo altri dettagli, per ora mi riprometto di documentarmi in merito.

E’ possibile che nel 2010 non sia possibile avere in MySQL una tabella con più di 10 campi TEXT?

Una risposta al post “Le sorprese di MySQL…”

  1. Gianfranco dice:

    nov 19, 10 at 11:33

    . mettendo tutti i campi tipo longtext, cambiando il tipo di tabella da INNODB a MYISAM e facendo l’update di tutti i campi che si vogliono modificare con un unica query il problema sparisce

    differenze fra INNODB e MYISAM qui:
    http://www.openskill.info/infobox.php?ID=1412


Scrivi un commento