it-swarm.it

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

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 :-)

27

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. SQL * 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;

Dati errati La lunghezza del campo fornisce un meccanismo aggiuntivo per rilevare/prevenire 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 verrà 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 la dimensione massima, l'applicazione allocherebbe una quantità di memoria significativamente maggiore di quella necessaria. 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 una società con clienti negli Stati Uniti ha un campo chiamato Stato di due caratteri, ci si aspetta 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.

12
Leigh Riffel

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 a varchar (30) potrebbe spingerti oltre il punto di non ritorno delle colonne (se tutti i 30 byte vengono utilizzati) potendo essere archiviati 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

9
SQLRockstar

Ho pensato di condividere un altro punto interessante, che ho trovato in na domanda Stack Overflow .

Risposta originale di: Nick Kavadias

Un motivo per NON utilizzare i campi max o text è che non è possibile eseguire ricostruzioni dell'indice online ovvero REVISIONE CON ONLINE = ON anche con SQL Server Enterprise Edition.

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.

7
Jeff

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.

6
Jeff

SET ANSI_PADDING ON?

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

4
gbn

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.

2
yrushka

Non credo 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.

2
bernd_k