MYSQL - Come risolvere il limite di dimensione della riga di 66 KBytes

Question

Ho un mysql db. Io uso innodb. 0ne delle mie tabelle contiene poco più di 10 colonne. L'ultima colonna ha un tipo di LONGTEXT e dovrebbe contenere codice html. Il problema è che per ogni record, quel campo non contiene il codice completo e si ferma sempre dopo la stessa quantità di caratteri. Il peso dei file html che cerco di inserire è di circa 60KO. Quindi immagino che ciascuno dei miei record superi il limite di dimensione della riga di mysql (66KO). Quello che vorrei sapere è se ci sono alcuni modi per estendere tale limite. Qualsiasi soluzione alternativa sarebbe molto apprezzata. Grazie in anticipo per gli input. Saluti. Marc

Answer 1

Non v'è alcun modo per estendere questo limite, in quanto non è dipendente dal motore di archiviazione ma è un hard limit on the server:

Ogni tabella (indipendentemente dal motore di archiviazione) ha una dimensione massima delle righe di 65.535 byte. I motori di archiviazione possono porre ulteriori vincoli su questo limite , riducendo la dimensione massima effettiva della riga.

In questo caso le soluzioni devono ruotare intorno rimandando lo stoccaggio di HTML per qualche altro posto - sul filesystem o sulla nuvola (S3) e quindi fare riferimento al nome del file nella colonna della tabella.

Answer 2

Quando si dice "quel campo non contiene il codice completo e si arresta sempre dopo la stessa quantità di caratteri", come si determina cosa contiene il campo? Sospetto che ciò che stai visualizzando sia stato troncato dalla variabile max_allowed_packet.

Come indicato nel MySQL manual:

La dimensione massima di un oggetto BLOB o TEXT è determinato dal suo tipo, ma il valore più grande in realtà si può trasmettere tra il client e il server è determinato dalla quantità di memoria disponibile e dimensione dei buffer di comunicazione. È possibile modificare la dimensione del buffer dei messaggi modificando il valore della variabile max_allowed_packet, ma è necessario farlo sia per il server che per il programma client. Ad esempio, sia mysql e mysqldump consente di modificare il valore max_allowed_packet lato client. Vedere Section 8.11.2, “Tuning Server Parameters”, Section 4.5.1, “mysql — The MySQL Command-Line Tool” e Section 4.5.4, “mysqldump — A Database Backup Program”. Si consiglia inoltre di confrontare le dimensioni dei pacchetti e la dimensione dei dati oggetti si memorizzano con i requisiti di archiviazione, vedere Section 11.5, “Data Type Storage Requirements”

Answer 3

I valori per (LONG) TEXT (e BLOB) sono non memorizzati "nella riga" ma al di fuori di esso. Quindi la dimensione del tuo HTML non contribuisce alla dimensione delle singole righe.

Dal manuale:

La rappresentazione interna di una tabella ha una dimensione massima delle righe di 65.535 byte, anche se il motore di memorizzazione è in grado di supportare file più grandi. Questa figura esclude BLOB o TEXT colonne, che contribuiscono solo 9 a 12 byte verso queste dimensioni

Per i dati BLOB e TEXT, le informazioni sono memorizzate internamente in una diversa area di memoria del buffer di riga.

(sottolineatura mia)

http://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html

Answer 4

La risposta accettata è sbagliata (o almeno abbastanza supponente) - Non voglio personalmente i dati memorizzati al di fuori del mio database, in quanto crea complicazioni in termini di procedure di backup e query transazionali.

Come altri hanno sottolineato, il manuale indica ripetutamente che le colonne BLOB e TEXT non contano per la dimensione totale della riga, ma sfortunatamente, con le impostazioni di configurazione predefinite, ciò non è vero, e si finisce per ottenere questo errore- Messaggio. (Il messaggio di errore non ha alcun senso, perché ti sta dicendo di utilizzare TEXT anziché VARCHAR per risolvere il problema, che già conosci.)

Il motivo di questa limitazione è il meccanismo di archiviazione predefinito, Antelope, che memorizza l'i primi 768 byte di colonne di lunghezza variabile nella riga - e una possibile soluzione è quella di utilizzare INNODB e passare il meccanismo di stoccaggio al meccanismo Barracuda memorizzazione alternativo:

SET GLOBAL innodb_file_format=Barracuda; 

Questo non avrà effetto immediato, perché questa impostazione è un valore predefinito per i nuovi file di database, quindi sarà necessario eliminare e ricreare l'intero database.

In alternativa, passare alla Barracuda (come sopra) e poi (in aggiunta) passare alla strategia di file-per-tavolo:

SET GLOBAL innodb_file_per_table=ON; 

Ancora una volta, questo non avrà effetto immediato, in quanto entrambe le impostazioni sono predefiniti per le nuove tabelle - quindi, ancora una volta, sarà necessario rilasciare e ricreare la tabella.

Se si cerca nella cartella dei dati MySQL dopo aver fatto ciò, è possibile confermare che sono stati creati file separati, ad es. per un database chiamato "data", e una tabella chiamata "test", dovresti vedere un file chiamato "data/test/bigtable.ibd".

Se non ti piace modificare le impostazioni globali in MySQL, prova SET SESSION anziché SET GLOBAL, ad es. immediatamente prima di eseguire le tue dichiarazioni CREATE TABLE.

Answer 5

L'abbiamo risolto con i seguenti passaggi.

Step-1: eseguire sotto query in MySql per impostare le variabili globali.

• SET GLOBAL innodb_file_format = Barracuda;
• SET GLOBAL innodb_file_per_table = ON;

Passaggio 2: selezionare la tabella da cui si verifica l'errore quando si tenta di salvare i dati di grandi dimensioni in una riga singola.

Step-3: Vai Operations

Step-4: Selezionare COMPRESSA da ROW_FORMAT. (Di default COMPACT e REDUNDANT saranno lì quando si impostano le variabili globali innodb_file_format e innodb_file_per_table si possono trovare altre opzioni come COMPRESSED e DYNAMIC)

Step-5: Fare clic su Vai.

:)