it-swarm-eu.dev

Jak dlouhé sloupce ovlivňují výkon a využití disku?

V našem současném projektu se často stává příliš často, že musíme rozšířit sloupce o několik znaků. Od varchar(20) do varchar(30) a tak dále.

Ve skutečnosti, na čem to opravdu záleží? Jak dobrý je tento optimalizovaný? Jaký je dopad toho, že povolíte 100 nebo 200 nebo dokonce 500 znaků pro normální „vstupní“ pole? E-mail může mít pouze 320 znaků, takže je v pořádku - je zde dobrý limit. Co ale získám, když ji nastavím na 200, protože neočekávám delší e-mailové adresy než tohle.

Naše tabulky obvykle nebudou mít více než 100 000 řádků a až 20 nebo 30 takových sloupců.

Nyní používáme SQL Server 2008, ale bylo by zajímavé vědět, jak různé DB řeší tento problém.

V případě, že je dopad velmi nízký - jak bych očekával, pomohlo by to získat několik dobrých argumentů (podložených odkazy?), Které by přesvědčily můj DBA, že tato paranoia s dlouhými poli není opravdu nutná.

V případě, že ano, jsem tu, abych se naučil :-)

27

Konkrétní odpověď na vaši otázku (alespoň pro Oracle a pravděpodobně i jiné databáze) je, že na délce pole nezáleží, pouze na délce dat. To by však nemělo být použito jako určující faktor týkající se toho, zda nastavit pole na jeho maximální přípustnou délku nebo ne. Zde je několik dalších problémů, které byste měli zvážit, než maximalizujete velikost polí.

Formátování Jakýkoli klientský nástroj, který formátuje data na základě velikosti polí, bude vyžadovat zvláštní aspekty formátování. Například Oracle SQL * Plus ve výchozím nastavení zobrazuje maximální velikost sloupců Varchar2, i když data mají pouze jeden znak. Porovnat ...

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;

Špatná data Délka pole poskytuje další mechanismus pro zachycení/zabránění špatných dat. Rozhraní by se nemělo pokoušet vložit 3 000 znaků do pole se 100 znaky, ale pokud je toto pole definováno jako 4 000 znaků, mohlo by to jen tak. Chyba nebude zachycena ve fázi zadávání dat, ale systém může mít potíže dále, když se jiná aplikace pokusí zpracovat data a tlumivky. Například, pokud se později rozhodnete indexovat pole v Oracle, překročili byste maximální délku klíče (v závislosti na velikosti bloku a zřetězení). Vidět…

create index i1 on f1(a);

Paměť Pokud klientská aplikace přiděluje paměť pomocí maximální velikosti, aplikace by přidělila podstatně více paměti, než je nutné. Aby se tomu zabránilo, muselo by se učinit zvláštní opatření.

Dokumentace - Velikost pole poskytuje další datový bod dokumentace o datech. Mohli bychom volat všechny tabulky t1, t2, t3 atd. A všechna pole f1, f2, f3 atd., Ale zadáním smysluplných jmen lépe porozumíme datům. Pokud má například tabulka adres pro společnost se zákazníky v USA pole nazvané Stát, což jsou dva znaky, očekáváme, že se v něm objeví zkratka dvou znakového stavu. Na druhé straně, pokud je pole sto znaků, můžeme očekávat, že se do pole objeví celé jméno státu.


Všechno, co bylo řečeno, se zdá být rozumné být připraven na změnu. To, že všechny vaše současné názvy produktů se vejdou do 20 znaků, neznamená, že vždy budou. Nechoďte přes palubu a nestavte to 1000, ale nechte prostor pro věrohodnou expanzi.

12
Leigh Riffel

Zde je pro vás dobrý výchozí bod.

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

Možná jsem pochopil tvou původní otázku. Uvidíme, jestli vám mohu najít několik dalších odkazů pro informaci.

Zde je dobrý odkaz na výběr typu dat: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Přechod z varchar (20) na varchar (30) se může zdát jako něco malého, ale je třeba více porozumět tomu, jak databázové struktury fungují, abyste si byli vědomi potenciálních problémů. Například přechod na varchar (30) by vás mohl posunout kolem bodu překlopení vašich sloupců (pokud by se všech 30 bytů využilo), aby bylo možné uložit na jednu stránku (méně než 8060 bytů). To povede ke zvýšení využití místa na disku, ke snížení výkonu a dokonce k další režii s vašimi protokoly transakcí.

Zde je odkaz na databázové struktury: http://technet.Microsoft.com/en-us/sqlserver/gg313756.aspx

Zde je jeden pro rozdělení stránek a protokolování trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

9
SQLRockstar

Myslel jsem, že bych sdílel další zajímavý bod, který jsem našel v otázka Stack Overflow .

Původní odpověď: Nick Kavadias

DŮLEŽITÉ nepoužívat max nebo textová pole je to, že nemůžete provádět online indexové přestavby tj. REBUILD WITH ONLINE = ON ani s SQL Server Enterprise Edition.

Považuji to za velkou nevýhodu při libovolném přidávání sloupců n/varchar (max) a podle serveru MS toto omezení proti opětovnému sestavování indexů online zůstává na serverech SQL Server 2008, 2008 R2 a Denali; takže to není specifické pro SQL Server 2005.

7
Jeff

V některých případech množství prostoru, které přidělíte pro pole varchar, ovlivní množství paměti přidělené pro řazení v paměti.

Našel jsem, že prezentace na serveru SQLWorkshops.com jsou provokativní, tato prezentace hovoří o případu, kdy se řazení do objednávky rozlévá do tempdb, protože pro pole char/varchar není přidělena dostatek paměti.

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

Toto webové vysílání bylo také prezentováno jako článek na následujícím webu:

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

V této prezentaci si všimněte, že sloupec, který je tříděn, není sloupec char/varchar, ale velikost prostoru přidělená pro sloupec varchar v paměti způsobuje v některých případech rozdíl ve výkonu dotazu.

6
Jeff

SET ANSI_PADDING ON?

Skončíte se spoustou koncových mezer ...

4
gbn

To záleží pouze na disku a délce znaků. Samozřejmě vyhledávání na datových typech char a indexech na těchto typech dat bude působit pomaleji než celé číslo, ale toto je další diskuse.

Datový typ Varchar je datový typ „variabilní“, takže pokud nastavíte limit varchar (500), je to maximální délka znaku pro toto pole. Minimální délka může být mezi 0 a 500. Na druhé straně se nárokované místo na disku bude lišit pro pole 10, 30 nebo 500 znaků.

Někdy jsem udělal test na datový typ varchar (800) a pro nulové hodnoty jsem použil 17 bajtů a pro každý vložený znak přidal ještě jeden bajt. Například řetězec 400 znaků měl na disku 417 bytů.

2
yrushka

Nemyslím si, že existuje rozdíl mezi tabulkami vytvořenými se sloupci varchar (20) nebo varchar ((8000)), pokud je skutečná maximální délka <= 20.

Na druhé straně, v některých případech, které uživatelům umožní ukládat delší řetězce, by je mohly povzbudit, aby to udělali.

2
bernd_k