Geschwindigkeitseinbussen durch große Tabellen?

[Mario Steinko]

Hi!

Ab welcher Größe hat man denn bei einer db Tabelle deutliche Geschwindigkeitseinbussen?
Ich habe eine Tabelle:
id | name | ... | related_table

Ab welcher Größe macht es denn Sinn diese Tabelle (intensiv genutzt mit JIONs, SELECT WHEREs und INSERTSs) in 4 Tabellen (und dafür ohne related_table) zu unterteilen?

1.000 Einträge?
  5.000 Einträge?
 10.000 Einträge?
 50.000 Einträge?
100.000 Einträge?
500.000 Einträge?
bei allem drüber wirds definitiv langsamer, das weiß ich aus eigener Erfahrung...

lg
Mario

[Cheatah]

Hi,

Ab welcher Größe macht es denn Sinn diese Tabelle (intensiv genutzt mit JIONs, SELECT WHEREs und INSERTSs) in 4 Tabellen (und dafür ohne related_table) zu unterteilen?

ab keiner. Gleichförmige Daten sind *immer* in der selben Tabellen.

bei allem drüber wirds definitiv langsamer, das weiß ich aus eigener Erfahrung...

Dann ist Deine Erfahrung ausbaufähig. Beschäftige Dich mit DB-Optimierung.

Cheatah

[Mario Steinko]

Hi,

»» Ab welcher Größe macht es denn Sinn diese Tabelle (intensiv genutzt mit JIONs, SELECT WHEREs und INSERTSs) in 4 Tabellen (und dafür ohne related_table) zu unterteilen?

ab keiner. Gleichförmige Daten sind *immer* in der selben Tabellen.

ok, thx

»» bei allem drüber wirds definitiv langsamer, das weiß ich aus eigener Erfahrung...

Dann ist Deine Erfahrung ausbaufähig. Beschäftige Dich mit DB-Optimierung.

Selbst ne optimierte DB muss beim durchsuchen vom 6 Mio. Datensätzen (hatte ich einmal) langsamer sein als bei 10. (zumindestens bei JIONs oder WHERE-Abfragen).

Das is simple Mathematik, selbst optimierte Baume wachen mit log.

lg
Mario

[Cheatah]

Hi,

Selbst ne optimierte DB muss beim durchsuchen vom 6 Mio. Datensätzen (hatte ich einmal) langsamer sein als bei 10.

ja, aber unwesentlich. Vergleichbar ist der Geschwindigkeitsunterschied mit dem Platzverbrauch der Zahl "6000000" gegenüber der Zahl "10": nur das 3.5-Fache, nicht das sechshunderttausend-Fache.

Das is simple Mathematik, selbst optimierte Baume wachen mit log.

Optimierte Indexe schränken möglichst schnell möglichst viel ein. Wenn schon bei der ersten Entscheidungsstelle nur noch der Bruchteil eines Promillbereichs übrig bleibt, wirst Du in einem Benchmark kaum Unterschiede zwischen dem Durchsuchen der beiden oben angedeuteten Tabellen messen können.

Cheatah