Große DB

[devas]

Hallo,

ich habe eine Tabelle die immer weiter anwächst und nun bald 1 GB Daten enthält und mehere 100K Datensätze.

Seit geraumer Zeit stelle ich fest das eine Abfrage immer länger dauert.

Meine Frage: Das die Abfrage länger dauert liegt es an der fülle der Daten, der Anzahl der Datensätze oder doch ehr am Server?

Ich weis nicht genau ob die Frage hier hingehört.

[IchBinIch]

Das kann man pauschal nie beantworten.

Aber eine Wechselwirkung:
Menge der Daten <=> Serverausrüstung
kann wohl niemand abstreiten.

Mit steigenden Daten sollte natürlich auch der Server gesteigert werden. Somit fällt es schwer zu sagen, was "schuld" ist.

Oft liegt es aber einfach am DB-Layout.

[unset]

Re: Große DB

Original geschrieben von devas

Meine Frage: Das die Abfrage länger dauert liegt es an der fülle der Daten, der Anzahl der Datensätze oder doch ehr am Server?

Preisfrage: Wo ist der Unterschied zwischen "die Fülle der Daten" und "die Anzahl der Datensätze"?

Jedenfalls: Evtl. ist die Tabelle nicht optimal indiziert. Wenn du zum Beispiel in einer Adressdatensatztabelle einen Index auf die Hausnummer legst, aber stets nach PLZ selectest, ist es kein Wunder, dass es irgendwann mal lange dauert.

Wobei ich natürlich auch nicht ausschließen will, dass es an der Hardware liegt. Vor allem vServer werden da gerne und schnell zickig.

[devas]

Mit fülle meine ich Menge in KB.

Beispiel:

Taballe hat 100k Zeilen mit insgesammt 500MB Platzbedarf.

Oder Tabelle hat 100k Zeilen mit 100MB Platzbedarf.

Was ist entscheident? Die Anzahl der Zeilen oder der Platzbedarf.




Verstehe ich es richitg das man den Index auf das legen sollte, wonach am meisten selectet wird?

[arkos]

du könntest auch anfangen, deine riesentabelle in mehrere untertabellen zu zerlegen. ist ein gängiges mittel...

zb wenns ne usertabelle ist, nimmst du anfangsbuchstaben. so haste aus einer großen tabelle schon 26 kleine gemacht, was die gezielte abfrage bannig schneller werden lässt...


edit:

Original geschrieben von devas
Verstehe ich es richitg das man den Index auf das legen sollte, wonach am meisten selectet wird?

ja.

[unset]

Original geschrieben von devas
Verstehe ich es richitg das man den Index auf das legen sollte, wonach am meisten selectet wird?

Genau. Du kannst aber auch mehrere Spalten indizieren. Jetzt komm aber bloß nicht auf die Schnapsidee, jede Spalte zu indizieren, das hat natürlich den selben Effekt, als wäre gar keine indiziert - unter Umständen hast du sogar einen negatven Performanceeffekt.

[devas]

Wenn ich jetzt, wo die Datenbank gefüllt ist, den index noch setze oder ändere bleibt das ohne Folgeschäden?

[unset]

Um einen Index zu setzen ist AFAIK ein ALTER TABLE notwendig. Das ist auf große Tabellen immer eine langwierige Geschichte. Wenn du am DB-Design rumfummelst solltest du ohnehin unmittelbar vorher ein Backup machen und ggf. Teilbereiche deiner Anwendung, die mit diesen Daten arbeitet nicht zugänglich machen (um Datenverlust weiter zu minimieren). Daraus alleine resultiert also schon, dass du das ganze eher zu einem Zeitpunkt machen solltest, wo deine Applikation kaum oder sogar gar nicht beansprucht wird. IdR also Nachts zwischen 2 und 5 Uhr.

Edit: Jetzt habe ich deine Frage gar nicht beantwortet: Ja, ein ALTER TABLE ist "ohne weiteres" auch möglich, wenn die Tabelle bereits Daten enthält

[devas]

Nur damit wir von dem selben sprechen.

Wenn ich eine Tabelle erstelle ist das rote dann der festgelegte index auf Datum.

CREATE TABLE `tabelle` (
`id` int(11) NOT NULL auto_increment,
`datum` varchar(50) collate latin1_general_ci NOT NULL,
.
.
.
.
.
.
.
PRIMARY KEY (`id`),
[COLOR=red]KEY `datum` (`datum`)[/COLOR]
)

[Abraxax]

ja

[arkos]

und für bestehende tabellen (wie du sie hast):

ALTER TABLE `tabelle` ADD INDEX my_index (datum)

zum nachlesen:
http://dev.mysql.com/doc/userguide/e...ter-table.html