Mysql - Performance ?

[Aiun]

hi,

folgende Situation, ich habe eine Tabelle in der Logmeldungen gespeichert werden.

zB. eine schleife geht alle User durch,

vermerkt jeweils für jeden User das die bearbeitung begonnen wurde

und updated später das die bearbeitung für diesen User heute abgeschlossen wurde.

Datensatzbeispiel:

UserId, Datum, Log_Start, Log_Ende, Log_Status

derzeit Stand, Ca 1.500.000 Datensätze.

Mache ich die Bearbeitung der User ohne das Logging, sind es pro user 0-1 Sekunde.

Baue ich das Logging ein (1x Insert, 1x Update) braucht es 5-7 Sekunden pro user.

Jemand eine Idee woran das liegen kann ?

[P3AC3MAK3R]

Liegt ein Index auf der Tabelle?

[Aiun]

Nur der Primärschlüssel.

Welche index-Konstrukte machen bei solchen Mengen an Datensätzen sinn ?

(oder "bis" welche Datenmengen sind sie sinnvoll ?)

[dr.dimitri]

Welche index-Konstrukte machen bei solchen Mengen an Datensätzen sinn ?

Solche, die es Dir erlauben die zu durchsuchende Datenmenge so stark wie möglich einzuschließen. Es macht keinen Sinn einen normalen Index auf ein Feld zu legen, welches in deiner 1,5 Mio Tabelle nur 100 verschiedene Ausprägungen hat.

(oder "bis" welche Datenmengen sind sie sinnvoll ?)

Warum bis? Eher ab wann. Und da kann es schonn sinnvoll sein, ab 50 Einträgen oder weniger einen Index zu verwenden - kommt auf die Anforderungen an.

Das Inserten eines Eintrages ist unabhängig von der Größe der Tabelle. Aber greifst Du auch mit dem PK wieder darauf zu wenn Du den Satz per Update änderst?

Falls es sich um ein anderes Feld (oder mehrere) handelt, dann wäre dies ein Indexkandidat.

Dim

[baba007]

ab 50 ein index, ja ne is klar

wie wärs mal mit einer Definition

[Amstelchen]

welche version wird eingesetzt?

habe ich das überlesen oder wurde das nicht angegeben?

eventuell hilfreich: MySQL AB :: Using the New MySQL Query Profiler

s'Amstel

[geloescht_JesterDay]

Nur der Primärschlüssel.

Und der Primätschlüssel ist?

eines von den genannten Feldern kann es ja nicht sein, höchstens eine Kombination von userid, Datum und Log_start vielleicht.

Das wär wohl auch der Index, den du zum Zugreifen benutzen musst, oder nicht? (wenn es nicht eh der PK ist)

Also sinn macht immer der Index, der deine Felder enthält die den Satz identifizieren den du suchst. Unabhängig von der Datenmenge.

Ich verstehe aber was du meinst, nämlich dass sich die Daten durch einen Index erhöhen (also Festplattenplatz).

Aber mal sehen wie deine Satzlänge so ist:

userid: 4byte (oder 8byte)

die Date und time felder müssten auch je 4 byte sein

und Status... tinyint? 1byte

Macht also 17 byte pro satz

rechnen wir mal mit 20, is schöner

1.500.000 * 20 byte

= 30.000.000 byte

= 29296,875 kB

=28,6102294921875 MB

Ich würde mir über die 28 MB jetzt nich so viel Gedanken machen, selbst wenn es jetzt 56 MB wären.

Das kannst du ruhig verdoppeln mit nem Index und auch dann sind da keine Probleme zu erwarten IMHO.

EDIT:

Ach ja, mit dem MySQL Admin kannst du dir ja anzeigen lassen, wieviel Platz die DB braucht und wieviel die Indexe einnehmen.

[dr.dimitri]

ab 50 ein index, ja ne is klar

Und was willst Du mir damit sagen?

Gehen wir von einer Standardblockgröße von 8KB aus und einer Durchschnittsgröße einer Row von 3KB (wie ich sagte - es kommt auf die Anwendungsfall drauf an) dann würde die Tabelle mindestens 19 Blocke belegen.

Ein Index auf ein nummerisches Feld innerhalb dieser Tabelle passt auf einen einzigen Block. Und nun eine einfache Rechenaufgabe:

Was ist schneller? Bei jeder Abfrage ohne Indexzugriff alle 19 Blöcke zu durchsuchen oder bei einem Indexzugriff den Indexblock + die benötigten Blöcke aus der Tabelle lesen.

Bei Bedarf kann ich dir auch gerne einen SQL Trace mitschicken.

Gehen wir weiter davon aus, dass es sich nicht um eine Adressverwaltung für den Computerladen von nebanan handelt, sondern um eine Anwendung die 5000 Transaktionen pro Sekunde zu bewältigen hat. Dann "könnte" sich dieser Indexzugriff durchaus postiv auf die CPU belsatung auswirken.

Es gibt noch weitere Gründe die für eine Inizierung von Tabellen mit wenigen Zeilen spricht (was nicht bedeutet, dass die Tabelle wenig Blöcke belegt), aber dann krieg ich wieder einen Rüffel von wegen Offtopic und so.

Dim

PS: Der Wikipedia Artikel wurde offensichtlich von einer MSSQL User geschrieben, denn ein Clustered Index ist in Oracle etwas komplett anderes.

[T-Yuma]

Mensch Aiun: Nimm ein paar Stored Procedures von Oracle und gut ist

[Amstelchen]

Mensch Aiun: Nimm ein paar Stored Procedures von Oracle und gut ist

oracle in allen ehren, ich arbeite seit langen damit, ABER: wenn er eine problemlösung für eine bestehende MySQL-applikation sucht, warum schlägst du ihm einen wechsel auf oracle vor?

wenn seine kupplung am auto scheuert, schlägst du ihm dann vor, ein neues zu kaufen?

verwundert,

s'Amstel

[T-Yuma]

Hey Aiun ist einfach ein alter Kollege von mir. Damit konnte ich ihn schon immer aufziehen. :e@sy War nur ein Spaß :beagolisc

[Aiun]

Yuma, ich sehe du hast immer noch nix dazu gelernt

wieder im lande hm ?

danke leute, ich werde mir wenn Zeit ist das nochmal ansehen, jetzt haben sich erstmal andere aufgaben dazwischen geschoben....wie immer