MySQL: grande VARCHAR vs. TEXT?

Ho una tabella dei messaggi in MySQL che registra i messaggi tra utenti. A parte i tipici ID e tipi di messaggio (tutti i tipi interi) ho bisogno di salvare il testo del messaggio come VARCHAR o TEXT. Sto impostando un limite front-end di 3000 caratteri, il che significa che i messaggi non verrebbero mai inseriti nel db più a lungo di questo.

C'è una logica per andare con VARCHAR (3000) o TEXT? C'è qualcosa nello scrivere VARCHAR (3000) che sembra in qualche modo controintuitivo. Ho passato altri post simili su Stack Overflow ma sarebbe utile ottenere visualizzazioni specifiche per questo tipo di archiviazione dei messaggi comuni.

• TEXTe BLOB può essere archiviato dalla tabella con la tabella che ha solo un puntatore alla posizione della memoria effettiva. La posizione in cui viene archiviato dipende da molte cose come la dimensione dei dati, la dimensione delle colonne, il formato riga e la versione di MySQL.

• VARCHARè memorizzato in linea con la tabella. VARCHARè più veloce quando la dimensione è ragionevole, il cui compromesso sarebbe più veloce dipende dai tuoi dati e dal tuo hardware, vorresti confrontare uno scenario del mondo reale con i tuoi dati.

Puoi prevedere quanto sarebbe lungo l'input dell'utente?

VARCHAR (X)

Caso: nome utente, e-mail, paese, oggetto, password

---

TESTO

Caso: messaggi, e-mail, commenti, testo formattato, html, codice, immagini, collegamenti

---

MEDIUMTEXT

Cassa: corpi json di grandi dimensioni, libri di lunghezza medio-corta, corde in CSV

---

LONGTEXT

Caso: libri di testo, programmi, anni di file di log, harry potter e il calice di fuoco, registrazione della ricerca scientifica

Giusto per chiarire la migliore pratica:

1. I messaggi in formato testo dovrebbero essere quasi sempre archiviati come TESTO (finiscono per essere arbitrariamente lunghi)

2. Gli attributi di stringa devono essere archiviati come VARCHAR (il nome utente di destinazione, l'oggetto, ecc ...).

Capisco che hai un limite per il front-end, che è ottimo fino a quando non lo è. * grin * Il trucco è pensare al DB come separato dalle applicazioni che si collegano ad esso. Solo perché un'applicazione pone un limite ai dati, ciò non significa che i dati siano intrinsecamente limitati.

Cosa c'è nei messaggi stessi che li costringe a non essere mai più di 3000 caratteri? Se è solo un vincolo di applicazione arbitrario (ad esempio, per una casella di testo o qualcosa del genere), utilizzare un TEXTcampo a livello di dati.

Disclaimer: non sono un esperto di MySQL ... ma questa è la mia comprensione dei problemi.

Penso che TEXT sia memorizzato al di fuori della riga mysql, mentre penso che VARCHAR sia memorizzato come parte della riga. C'è una lunghezza massima di riga per le righe mysql .. quindi puoi limitare la quantità di altri dati che puoi archiviare in una riga usando VARCHAR.

Anche a causa del fatto che VARCHAR fa parte della riga, sospetto che le query che guardano quel campo saranno leggermente più veloci di quelle che usano un blocco TEXT.

Risposta breve: nessuna differenza pratica, prestazionale o di archiviazione.

Risposta lunga:

Non esiste sostanzialmente alcuna differenza (in MySQL) tra VARCHAR(3000)(o qualsiasi altro limite di grandi dimensioni) e TEXT. Il primo troncerà a 3000 caratteri ; quest'ultimo verrà troncato a 65535 byte . (Faccio una distinzione tra byte e caratteri perché un personaggio può prendere più byte.)

Per limiti minori VARCHAR, ci sono alcuni vantaggi TEXT.

• "più piccolo" significa 191, 255, 512, 767 o 3072, ecc., a seconda della versione, del contesto e CHARACTER SET.
• INDEXessono limitati nella dimensione di una colonna che può essere indicizzata. (767 o 3072 byte ; dipende dalla versione e dalle impostazioni)
• Tabelle intermedie create da complessi SELECTs sono gestite in due modi diversi: MEMORIA (più veloce) o MyISAM (più lenta). Quando sono coinvolte colonne "grandi", la tecnica più lenta viene automaticamente selezionata. (Cambiamenti significativi in ​​arrivo nella versione 8.0; quindi questo punto elenco è soggetto a modifiche.)
• Relativamente all'elemento precedente, tutti i TEXTtipi di dati (invece di VARCHAR) passano direttamente a MyISAM. Cioè, TINYTEXTè automaticamente peggio per le tabelle temporanee generate rispetto all'equivalente VARCHAR. (Ma questo porta la discussione in una terza direzione!)
• VARBINARYè come VARCHAR; BLOBè come TEXT.

Confutazione ad altre risposte

La domanda originale poneva una cosa (quale tipo di dati usare); la risposta accettata ha risposto a qualcos'altro (archiviazione non registrata). Quella risposta non è più aggiornata.

Quando questo thread è stato avviato e risposto, c'erano solo due "formati di riga" in InnoDB. Poco dopo furono introdotti altri due formati ( DYNAMICe COMPRESSED).

Il percorso di archiviazione per TEXTe VARCHAR()si basa sulla dimensione , non sul nome del tipo di dati . Per una discussione aggiornata sull'archiviazione on / off-record di colonne di testo / BLOB di grandi dimensioni, vedere questo .

Le risposte precedenti non insistono abbastanza sul problema principale: anche in domande molto semplici come

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 

può essere richiesta una tabella temporanea e, se VARCHARè coinvolto un campo, viene convertito in un CHARcampo nella tabella temporanea. Quindi se nella tua tabella hai scritto 500.000 righe con un VARCHAR(65000)campo, questa sola colonna userà 6.5 * 5 * 10 ^ 9 byte. Tali tabelle temporanee non possono essere gestite in memoria e vengono scritte su disco. Ci si può aspettare che l'impatto sia catastrofico.

Fonte (con metriche): https://nicj.net/mysql-text-vs-varchar-performance/ (si riferisce alla gestione di TEXTvs VARCHARnel motore di archiviazione MyISAM "standard" (?). Potrebbe essere diverso in altri, ad es. InnoDB.)

C'è una GRANDE differenza tra VARCHAR e TEXT. Mentre i campi VARCHAR possono essere indicizzati, i campi TEXT non possono. I campi di tipo VARCHAR sono memorizzati in linea mentre TEXT sono archiviati offline, solo i puntatori ai dati TEXT sono effettivamente memorizzati nei record.

Se devi indicizzare il tuo campo per una ricerca più veloce, aggiorna o elimina rispetto a VARCHAR, non importa quanto sia grande. Un VARCHAR (10000000) non sarà mai lo stesso di un campo TEXT perché questi due tipi di dati sono di natura diversa.

• Se si utilizza il campo solo per l'archiviazione
• non ti interessa il ripristino della velocità dei dati
• ti interessa la velocità ma utilizzerai l'operatore '% LIKE%' nella tua query di ricerca, quindi l'indicizzazione non sarà di grande aiuto
• non è possibile prevedere un limite per la lunghezza dei dati

che andare per TEXT.

Varchar è per piccoli dati come indirizzi e-mail, mentre Testo è per dati molto più grandi come articoli di notizie, Blob per dati binari come immagini.

Le prestazioni di Varchar sono più potenti perché vengono eseguite completamente dalla memoria, ma non sarà così se i dati sono troppo grandi come varchar(4000)ad esempio.

Il testo, d'altra parte, non si attacca alla memoria ed è influenzato dalle prestazioni del disco, ma è possibile evitarlo separando i dati di testo in una tabella separata e applicare una query di join sinistro per recuperare i dati di testo.

Il BLOB è molto più lento, quindi usalo solo se non hai molti dati come 10000 immagini che costeranno 10000 record.

Segui questi suggerimenti per la massima velocità e prestazioni:

1. Usa varchar per nome, titoli, e-mail

2. Usa testo per dati di grandi dimensioni

3. Separare il testo in diverse tabelle

4. Usa le query Left Join su un ID come un numero di telefono

5. Se hai intenzione di usare Blob, applica gli stessi suggerimenti del testo

Ciò farà sì che le query costino millisecondi su tabelle con dati> 10 M e dimensioni garantite fino a 10 GB.