In che modo le colonne lunghe influiscono sulle prestazioni e sull'utilizzo del disco?


26

Nel nostro progetto attuale succede troppo spesso, che dobbiamo estendere le colonne di un paio di personaggi. Da varchar(20)a varchar(30)e così via.

In realtà, quanto conta davvero? Quanto è ottimizzato questo? Qual è l'impatto di consentire solo 100 o 200 o anche 500 caratteri per i normali campi di "input"? Un'email può avere solo 320 caratteri, quindi ok - c'è un buon limite lì. Ma cosa ottengo se impostato su 200, perché non mi aspetto indirizzi di posta elettronica più lunghi di così.

Di solito le nostre tabelle non avranno più di 100.000 righe e fino a 20 o 30 di tali colonne.

Usiamo SQL Server 2008 ora, ma sarebbe interessante sapere come diversi DB gestiscono questi problemi.

Nel caso in cui l'impatto sia molto basso - come mi aspetterei, sarebbe utile ottenere alcuni buoni argomenti (supportati da collegamenti?) Per convincere il mio DBA, che questa paranoia a campo lungo non è davvero necessaria.

In caso affermativo, sono qui per imparare :-)

Risposte:


12

La risposta specifica alla tua domanda (almeno per Oracle e probabilmente altri database) è che la lunghezza del campo non ha importanza, ma solo la lunghezza dei dati. Tuttavia, questo non dovrebbe essere usato come fattore determinante per stabilire se impostare il campo alla sua lunghezza massima consentita o meno. Ecco alcuni altri problemi che dovresti considerare prima di massimizzare le dimensioni dei campi.

Formattazione Qualsiasi strumento client che formatta i dati in base alla dimensione dei campi richiederà particolari considerazioni sulla formattazione. Oracle * Plus di Oracle, ad esempio, per impostazione predefinita visualizza la dimensione massima delle colonne Varchar2 anche se i dati sono lunghi solo un carattere. Confrontare…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Bad dati lunghezza campo fornisce un ulteriore meccanismo di cattura / evitare che dati errati. Un'interfaccia non dovrebbe tentare di inserire 3000 caratteri in un campo di 100 caratteri, ma se quel campo è definito come 4000 caratteri, potrebbe semplicemente. L'errore non verrebbe rilevato nella fase di immissione dei dati, ma il sistema potrebbe avere problemi più in basso quando un'altra applicazione tenta di elaborare i dati e soffoca. Ad esempio, se in seguito decidessi di indicizzare il campo in Oracle, supereresti la lunghezza massima della chiave (a seconda della dimensione del blocco e della concatenazione). Vedere…

create index i1 on f1(a);

Memoria Se l'applicazione client alloca memoria utilizzando le dimensioni massime, l'applicazione allocerebbe molta più memoria del necessario. Considerazioni speciali dovrebbero essere fatte per evitare questo.

Documentazione La dimensione del campo fornisce un altro punto di documentazione per i dati. Potremmo chiamare tutte le tabelle t1, t2, t3, ecc. E tutti i campi f1, f2, f3, ecc., Ma specificando nomi significativi comprendiamo meglio i dati. Ad esempio, se una tabella di indirizzi per un'azienda con clienti negli Stati Uniti ha un campo chiamato Stato di due caratteri, ci aspettiamo che l'abbreviazione dello stato di due caratteri vada in esso. D'altra parte, se il campo è composto da cento caratteri, potremmo aspettarci che il nome completo dello stato venga inserito nel campo.


Detto questo, sembra prudente essere preparati al cambiamento. Solo perché tutti i nomi dei tuoi prodotti oggi si adattano a 20 caratteri non significa che lo faranno sempre. Non esagerare e renderlo 1000, ma lasciare spazio per un'espansione plausibile.



La documentazione è una buona aggiunta qui che non ho visto altrove.
jeteon,

9

Ecco un buon punto di partenza per te.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Potrei aver frainteso la tua domanda originale. Fammi vedere se riesco a trovarti qualche altro link come riferimento.

Ecco un buon riferimento alle selezioni del tipo di dati: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Passare da varchar (20) a varchar (30) può sembrare qualcosa di piccolo, ma è necessario capire di più su come funzionano le strutture di database per essere consapevoli dei potenziali problemi. Ad esempio, andare su varchar (30) potrebbe spingerti oltre il punto di non ritorno delle colonne (se tutti i 30 byte vengono utilizzati) potendo essere archiviato su una pagina (meno di 8060 byte). Ciò comporterà un aumento dello spazio su disco utilizzato, una riduzione delle prestazioni e persino un sovraccarico aggiuntivo con i registri delle transazioni.

Ecco un link per le strutture del database: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Eccone uno per le suddivisioni di pagina e la registrazione trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

Ho pensato di condividere un altro punto interessante, che ho trovato nella seguente domanda SO:

/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Risposta originale di: Nick Kavadias

Un motivo per NON utilizzare i campi max o text è che non è possibile eseguire [ricostruzioni di indici online] [1] ovvero REBUILD WITH ONLINE = ON anche con SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "ricostruzioni di indici online"

Considererei questo un grosso svantaggio quando si aggiungono arbitrariamente colonne n / varchar (max) e, secondo il sito MS, questa restrizione a fare ricostruzioni di indici online rimane in SQL Server 2008, 2008 R2 e Denali; quindi non è specifico per SQL Server 2005.

Grazie Jeff


6

In alcuni casi, la quantità di spazio allocata per un campo varchar influirà sulla quantità di memoria allocata per gli ordinamenti in memoria.

Ho trovato stimolanti le presentazioni su SQLWorkshops.com, questa presentazione parla di un caso in cui un ordinamento per un ordine si sta riversando in tempdb perché non viene allocata memoria sufficiente per i campi char / varchar.

http://webcasts2.sqlworkshops.com/webcasts.asp

Questo webcast è stato presentato anche come articolo sul seguente sito Web:

http://www.mssqltips.com/tip.asp?tip=1955

Notare in questa presentazione che la colonna su cui si sta ordinando non è la colonna char / varchar, ma la quantità di spazio allocata per la colonna varchar in memoria fa la differenza nelle prestazioni della query in alcuni casi.


4

SET ANSI_PADDING ON?

Si finisce con un sacco di spazio bianco finale ...


3

Importa solo in relazione allo spazio su disco e alla lunghezza dei caratteri. Ovviamente la ricerca sui tipi di dati char e sugli indici su questo tipo di dati agirà più lentamente dell'intero, ma questa è un'altra discussione.

Il tipo di dati Varchar è un tipo di dati "variabile", quindi se si imposta un limite di varchar (500) di questo è la lunghezza massima dei caratteri per quel campo. La lunghezza minima può essere compresa tra 0 e 500. D'altro canto, lo spazio su disco richiesto sarà diverso per i campi di 10, 30 o 500 caratteri.

A volte ho fatto un test per il tipo di dati varchar (800) e per i valori null avevo 17 byte usati e per ogni carattere inserito ha aggiunto un altro byte. Ad esempio, una stringa di 400 caratteri aveva 417 byte utilizzati sul disco.


3

Non penso che ci sia alcuna differenza tra le tabelle create con colonne di varchar (20) o varchar ((8000), purché la lunghezza massima effettiva sia <= 20.

D'altra parte, in alcuni casi dare agli utenti la possibilità di memorizzare stringhe più lunghe potrebbe incoraggiarli a farlo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.