Re: varchar versus char


[ ruban.de ] [ Antworten ] [ Forum ]

Geschrieben von Gunnar Beck on Dezember 17, 2003 um 15:38:

Als Antwort auf varchar versus char geschrieben von Stefanie on Dezember 17, 2003 um 11:18:

Hallo Stefanie,

das eigentliche Kriterium für die Entscheidung varchar vs. char sollte nicht die Länge sein, sondern die Frage: Wie stark wird die durchschnittliche Länge der Strings von der maximalen Länge abweichen?

Varchars bestehen aus 2 Byten Längeninformation und speichern anschließend wirklich nur die benutzten Characters ab. Somit ist dieser Datentyp richtig Klasse, wenn ich lange Texte (z.B. 250 Charakter) zulassen möchte, aber die meisten Eintragungen doch nur 40 Characters beinhalten. Während Varchar nur 42 Bytes benötigt, verschwendet CHAR die gesamten 250 Byte. Die Einsparung an Speicherplatz bedeutet sofortigen Performancegewinn. Immerhin passen mehr Zeilen auf eine Seite und somit ist weniger Platz im Bufferpool, respektive I/O notwendig.

Keinen Sinn macht die Nutzung von varchar bei Strings, die sowiso immer die selbe Länge haben, wie z.B. Seriennummern, Teilenummern, etc.

Natürlich hat etwas mit so vielen Vorteilen auch Nachteile:

1.) Keine absolute Adressierung mehr möglich
In veralteten DB2 Performancebüchern wird immer wieder darauf hingewiesen, daß bei der Benutzung von Varchars der Offset einer Row nicht vorher berechnet werden kann. In der heutigen Welt fallen die paar CPU Zyklen aber gar nicht in's Gewicht.

2.) Gefahr von Page Overflows
Heikel wird die Angelegenheit bei Updates. Angenommen, anfangs sind die Inhalte der Varchar Felder fast leer. DB2 wird also sehr viele Zeilen pro Seite packen. Wenn nun ein Update auf ein Varcharfeld dafür sorgt, daß der String länger wird, so passt die Zeile unter umständen nicht mehr auf die Seite. In diesem Fall wird die Zeile auf eine andere Seite bewegt, auf der noch genug Platz ist. Damit nicht alle Index Seiten upgedated werden müssen, hinterlässt DB2 am Originalspeicherort einen Verweis.
Wenn sich der selbe String mehrfach in seiner Länge ändert können diese Verweisketten beliebig lang werden. Entsprechend steigt dann das I/O Volumen. In diesem Fall hilft dann nur ein reorg der Tabelle. Um herauszufinden, wie viele Seiten bereits von diesen "Overflows" betroffen sind, prüfe nach jedem Runstats die Wert Overflow.

Ich hoffe, diese Kurzeinführung reicht.

Gruß
Gunnar

www.marvinconsult.de





Antworten:


Schreibe eine Antwort

Name:   
E-Mail:  

Thema:

Kommentar:

Optionale Link URL:   
Link Titel:                  
Optionale Image URL:


[ Antworten ] [ Forum ]