Vorgehen bei ALTER TABLE / Performance

Hallo auch,

ich habe ein Problem mit einer Tabelle. Eine Spalte ist zu klein
definiert, sie ist auf den Typ DECIMAL(10,2) gesetzt. Sinnvoll wäre
allerdings DECIMAL(15,2). Nun stellt sich mir die Frage, wie lange ein
entsprechendes ALTER TABLE in einer Tabelle mit rund 12 Mio Datensätzen
dauern würde.
Dazu nun meine Frage: Wird bei dieser Art des ALTER TABLE nur irgendwo
ein Typ-Feld geändert, so dass das Update im Bereich von Millisekunden
liegt oder rechnet MySQL die Felder um (Was inhaltlich gesehen ja
sinnlos wäre). Im letzteren Fall, kennt ihr da Richtwerte wie hoch die
Geschwindigkeit etwa wäre (mir ist bewusst, dass dies auch von der
Hardware abhängt :)). Welche Einflussfaktoren sind in diesem Fall
außerdem für die Performance relevant?

TIA
Marcus
--
"Demokratie ist ein Verfahren, das garantiert, daß wir nicht besser
regiert werden, als wir es verdienen."
George Bernard Shaw

Re: Vorgehen bei ALTER TABLE / Performance

Marcus Schwarz wrote:
>
> ich habe ein Problem mit einer Tabelle. Eine Spalte ist zu klein
> definiert, sie ist auf den Typ DECIMAL(10,2) gesetzt. Sinnvoll wäre
> allerdings DECIMAL(15,2). Nun stellt sich mir die Frage, wie lange ein
> entsprechendes ALTER TABLE in einer Tabelle mit rund 12 Mio Datensätzen
> dauern würde.
> Dazu nun meine Frage: Wird bei dieser Art des ALTER TABLE nur irgendwo
> ein Typ-Feld geändert, so dass das Update im Bereich von Millisekunden
> liegt oder rechnet MySQL die Felder um (Was inhaltlich gesehen ja
> sinnlos wäre).

Wie so oft: das kommt drauf an. Laut
http://dev.mysql.com/doc/internals/en/myisam-column-attribut es.html

speichert MySQL ab Version 5 und bei Benutzung von MyISAM-Tabellen
DECIMAL in 4-Byte-Häppchen, die jeweils für 9 Dezimalstellen gut sind.
Sowohl DECIMAL(10,x) als auch DECIMAL(15,x) brauchen also 8 Byte. Da
auch die Anzahl der Nachkommastellen gleich bleibt, könnte man diese
Änderung durchführen, ohne die Daten selber anzufassen. Das wäre sehr
gut, weil man dann auch keine Indizes anfassen muß.

Es kann aber durchaus sein, daß ALTER TABLE *immer* als "neue Tabelle
anlegen, Daten kopieren, Indexe neu machen" implementiert ist. Dazu
müßte man in den Code schauen und dafür bin ich zu faul. Ist ja
schließlich nicht mein Problem ;-)

Also wirst du es wohl ausprobieren müssen.

> Welche Einflussfaktoren sind in diesem Fall
> außerdem für die Performance relevant?

Eigentlich alles. Die Daten müssen gelesen, konvertiert und geschrieben
werden. Das fordert I/O und CPU gleichermaßen. Für den Aufbau der
Indexe ist außerdem RAM wichtig. Eventuell interessant ist noch, daß
MySQL ALTER TABLE mit nur einem Thread durchzieht. Eine Maschine mit
einer schnellen CPU ist also besser als eine mit vielen langsamen.


XL

Re: Vorgehen bei ALTER TABLE / Performance

Marcus Schwarz wrote:
> ich habe ein Problem mit einer Tabelle. Eine Spalte ist zu klein
> definiert, sie ist auf den Typ DECIMAL(10,2) gesetzt. Sinnvoll wäre
> allerdings DECIMAL(15,2). Nun stellt sich mir die Frage, wie lange ein
> entsprechendes ALTER TABLE in einer Tabelle mit rund 12 Mio Datensätzen
> dauern würde.
> Dazu nun meine Frage: Wird bei dieser Art des ALTER TABLE nur irgendwo
> ein Typ-Feld geändert, so dass das Update im Bereich von Millisekunden
> liegt oder rechnet MySQL die Felder um (Was inhaltlich gesehen ja
> sinnlos wäre).

MySQL kopiert bei allen strukturellen Änderungen die komplette Tabelle
in eine neue, konvertiert dabei die geänderten Felder und baut den Index
neu auf. Das muss es auch, denn wenn du, wie bei dir, ein Feld
vergrößerst, dann ändert sich das Layout der Zeilen in der Tabelle.

> Im letzteren Fall, kennt ihr da Richtwerte wie hoch die
> Geschwindigkeit etwa wäre (mir ist bewusst, dass dies auch von der
> Hardware abhängt :)). Welche Einflussfaktoren sind in diesem Fall
> außerdem für die Performance relevant?

Bei einigen meiner Tabellen mach' ich das inzwischen äußerst ungern.
Sind zwar "nur" 5 Millionen Datensätze, das kopieren verbraucht aber gut
und gerne mal 10-20 Minuten (Genaue Zeiten weiß ich nicht, ich geh'
immer Kaffeetrinken, wenn es so weit ist).

Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: Vorgehen bei ALTER TABLE / Performance

Kai Ruhnau schrieb:

> Bei einigen meiner Tabellen mach' ich das inzwischen äußerst ungern.
> Sind zwar "nur" 5 Millionen Datensätze, das kopieren verbraucht aber gut
> und gerne mal 10-20 Minuten (Genaue Zeiten weiß ich nicht, ich geh'
> immer Kaffeetrinken, wenn es so weit ist).

Danke Dir und Axel.
Das hört sich wohl nach Nachtschicht und *heul, das Programm geht grad
nicht* an :(

m*
--
"Wenn das Leben eine Zitrone ist - mach´ Limo daraus"
Bernhard Pompey

Re: Vorgehen bei ALTER TABLE / Performance

Marcus Schwarz wrote:
>
> Dazu nun meine Frage: Wird bei dieser Art des ALTER TABLE nur irgendwo
> ein Typ-Feld geändert, so dass das Update im Bereich von Millisekunden
> liegt oder rechnet MySQL die Felder um (Was inhaltlich gesehen ja
> sinnlos wäre).

Ich verweise dazu mal auf:

http://lists.mysql.com/mysql/202489

Seitdem dürfte sich da strukturell nicht viel geändert haben.


> Im letzteren Fall, kennt ihr da Richtwerte wie hoch die
> Geschwindigkeit etwa wäre (mir ist bewusst, dass dies auch von der
> Hardware abhängt :)).

Hoch? Eher niedrig ...


> Welche Einflussfaktoren sind in diesem Fall außerdem für die
> Performance relevant?

Was passiert sonst noch auf dem System?
Benutzt nur Mysql die Platte oder schreiben noch andere
Anwendungen?
Arbeiten noch andere Clients auf der Datenbank oder ist die
ansonsten im Leerlauf?


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Vorgehen bei ALTER TABLE / Performance

Andreas Scherbaum schrieb:

>> Welche Einflussfaktoren sind in diesem Fall außerdem für die
>> Performance relevant?
>
> Was passiert sonst noch auf dem System?
> Benutzt nur Mysql die Platte oder schreiben noch andere
> Anwendungen?
> Arbeiten noch andere Clients auf der Datenbank oder ist die
> ansonsten im Leerlauf?

Auf der Maschine läuft nur die Datenbank, der Apache wird nur zu
administrativen Zwecken genutzt. Auf den DB-Server greifen drei
Webserver zu, die im Schnitt etwa 2.000 Nutzer zeitgleich bedienen.

Der DB-Server pfeift dabei zu Spitzenzeiten bereits aus dem letzten Loch.
Aufgrund der bisherigen Antworten werden wir wohl noch ein wenig warten
mit dem Update der Tabelle und das mit einem Upgrade des Servers
verbinden, das sowieso in einigen Wochen anstünde.

Grüße
m*
--
Murphy sagt:
"Systemmeldungen auf die wir warten
Fehler 153: Linux gefunden. (A)dventure-Buch kaufen (S)elbstmord begehen
(P)rogrammierer einstellen?"

Re: Vorgehen bei ALTER TABLE / Performance

On 31.01.2007 14:46, Kai Ruhnau wrote:
> MySQL kopiert bei allen strukturellen Änderungen die komplette Tabelle
> in eine neue, konvertiert dabei die geänderten Felder und baut den Index
> neu auf. Das muss es auch, denn wenn du, wie bei dir, ein Feld
> vergrößerst, dann ändert sich das Layout der Zeilen in der Tabelle.

Ist das wirklich immer so auch z.B. wenn man von VARCHAR(10) auf
VARCHAR(20) ändert? Das wäre ja furchtbar, weil die DB sich dann mehr
Arbeit als nötig macht. Oder speichert MySQL immer die volle Länge, so
wie das z.B. MaxDB auch macht?

Ciao

robert

Re: Vorgehen bei ALTER TABLE / Performance

Robert Klemme wrote:
>
> Das wäre ja furchtbar, weil die DB sich dann mehr Arbeit als nötig macht.

Muss ja keinen Sinn machen, was da passiert.

Im Normalfall würde ich sagen: Patches sind willkommen.
Aber bei Mysql weiss ich nicht so wirklich, wie das gehandhabt wird.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)