Hi,
mal ne Frage zu VARCHARs. Soweit ich weiss ist das tolle an varchars, dass diese nur soviel Speicher belegen, wie in ihnen auch tatsächlich abgelegt ist. Trotzdem kann man varchars in der Länge begrenzen, und standardmäßig sind diese Grenzen sogar recht klein gewählt.
Macht es eigentlich irgendeinen Unterschied (Performance oder Speicherverbrauch) ob ich nen varchar(2) oder nen varchar(100000) definiere, wenn der tatsächliche gespeicherte Wert gleich lang ist?
Gruß Michael
Varchar
gepostet vor 17 Jahre, 7 Monate von MichaelB
gepostet vor 17 Jahre, 7 Monate von Klaus
Eigentlich nicht, denn das Limit wird nur zum Abschneiden zu langer Zeichenketten genutzt, aber manche SQL-Engines ignorieren das sogar ganz.
gepostet vor 17 Jahre, 7 Monate von exe
Nein, macht keinen Unterschied. Ein Varchar belegt immer die Länge des Strings + 1 oder 2 Byte um die Längeninformation zu speichern (1 Byte bei Varchars < 255, 2 Byte bei Varchars > 255 und < 65.532).
Beachte: die maximale Länge eines Varchars liegt bei 65.532, und zwar in Byte, nicht in Zeichen. Bei latin1 ist das kein Unterschied, bei UTF-8 aber doch. Da sind die 65.532 Byte eher was um die 32.000 Zeichen.
Beachte: die maximale Länge eines Varchars liegt bei 65.532, und zwar in Byte, nicht in Zeichen. Bei latin1 ist das kein Unterschied, bei UTF-8 aber doch. Da sind die 65.532 Byte eher was um die 32.000 Zeichen.
gepostet vor 17 Jahre, 7 Monate von Störti
Bei kleinen Feldern würde ich aber immer CHAR empfehlen, da man dann auf eine feste Zeilenlänge kommt. Dadurch sind SELECTS in grossen Tabellen deutlich schneller, wenn man (warum auch immer) mal nicht auf Indizies zurückgreifen kann. Bei VARCHAR muss SQL immer erst bei jeder Zeile gucken, wie lang sie ist, was Zeit braucht...
gepostet vor 17 Jahre, 7 Monate von Klaus
Außerdem fragmentiert ein Varchar recht schnell.
gepostet vor 17 Jahre, 7 Monate von MichaelB
OK, dann haben die Diskussionen bei uns im Büro endlich ein Ende
Danke
Danke
gepostet vor 17 Jahre, 7 Monate von Drezil
Original von Störti
Dadurch sind SELECTS in grossen Tabellen deutlich schneller, wenn man (warum auch immer) mal nicht auf Indizies zurückgreifen kann.
warum? weil die x-te zeile an position (x-1)*Zeilenlänge zu finden ist. da braucht man nicht in einer tabelle nachschauen, wo jetzt zeile 3453 beginnt.
gepostet vor 17 Jahre, 7 Monate von exe
Original von Störti
Bei kleinen Feldern würde ich aber immer CHAR empfehlen, da man dann auf eine feste Zeilenlänge kommt. Dadurch sind SELECTS in grossen Tabellen deutlich schneller, wenn man (warum auch immer) mal nicht auf Indizies zurückgreifen kann. Bei VARCHAR muss SQL immer erst bei jeder Zeile gucken, wie lang sie ist, was Zeit braucht...
Kann man so generell nicht sagen. Zum einen kriegst du feste Zeilenlängen nur, wenn alle Spalte eine feste Breite haben. Zum anderen ist der Vorteil, den Drezil da erwähnt, auch nur theoretisch: Sprünge in der Tabelle kannst du nur machen, wenn du keinen Tablescan machst (wenn du also einen Index nutzt). In dem Fall, bringen dir die fixen Zeilenlängen nichts mehr. Das Ansehen der Längeninformation einer VARCHAR-Spalte ist in dem Zusammenhang kein wirkliches Problem. Eine Zeile wird i.d.r sowieso als ganzes aus der Tabelle gelesen (solange die Zeile nicht über mehrere Diskpages geht, was nur bei sehr großen Zeilen der Fall wäre). Da ist die Lesezeit von der Festplatte höher als 1 Byte aus der Zeile zu lesen ...
Anders gesagt: wenn du keinen Index nutzt dann machst du sowieso einen vollen Tablescan und schaust jede Zeile an.
gepostet vor 17 Jahre, 7 Monate von n26
(sry habe nur mit BB Code rumgespielt und ausversehen statt Vorschau speichern gedrückt :/ - Beitrag bitte ignorieren und löschen)
gepostet vor 17 Jahre, 7 Monate von mifritscher
Naja, die meisten Tabellen werden aber recht schnell im Arbeitsspeicher gecacht, und da bringt es unter Umständen schon was feste Größen zu haben, weil die Positionen viel leichter berechnet werden können. Schlimm wird es wenn Tabelle in Folge von Varchars fragmentiert ist...