mysql: index oder nicht index

vorgeschichte: ich will den status eines onlinespiels mitloggen. nun dachte ich mir u.a. folgende tabelle: charid, timestamp, x, y. in einer anderen tabelle werden dann sachen wie name, account oder gilde der entsprechenden chars gespeichert.

da ich die daten ja auch auswerten will und grafisch anzeigen will, überlege ich nun, ob index oder nicht. bzw. wofür ist eigentlich ein primärschlüssel?

derzeit hab ich mal probeweise eine tabelle mit 72.000 zeilen gefüllt und festgestellt, daß fast 50% des speicehrplatzes für index drauf geht. ich hab derzeit nen index auf charid und timestamp.

Code:

test6
Feld 	Typ 	Null 	Standard 	Verweise 	Kommentare 	MIME
charid  smallint(5) 	Nein  	0  	  	  	 
zeit  	int(10) 	Nein  	0  	  	  	 
x  	smallint(4) 	Nein  	0  	  	  	 
y  	smallint(4) 	Nein  	0  	  	  	 


 Indizes :
Name 	Typ 	Kardinalität 	Feld
charid 	INDEX 	72000 	charid
 	 	 	zeit


 Speicherplatzverbrauch :
Typ 	Verbrauch
Daten 	792.000 	Bytes
Index 	735.232 	Bytes
Insgesamt 	1.491 	KB
	  	 Zeilenstatistik :
Angaben 	Wert
Format 	starr
Zeilen 	72.000
Zeilenlänge ø 	11
Zeilengröße ø 	21 Bytes
Erzeugt am 	07. Oktober 2004 um 19:22
Aktualisiert am 	07. Oktober 2004 um 19:22
Letzter Check am 	07. Oktober 2004 um 19:22

nun ist die frage, ob sich ein index auf zeit und charid auszahlt, da ich ja auch etwas mit dem platz sparen muß.
es wird sicherlich ein paar abfragen geben, für die onlinezeit (1 eintrag = 1minute online) bzw. wo der char wann war (also ne karte wo man seinen weg nachverfolgen kann bzw. seine lieblingsplätze sieht) daher ist die frage, ob sich ein index über die zeit überhaupt auszahlt, vor allem wo sie sowieso automatisch der größe nach sortiert ist. würde etwa 20% platz sparen.

tia

MIK

sorry, aber imho is' da ein kleiner fehler im index... nämlich charid&zeit sollte imho nicht in einem gemeinsamen index sein

ausserdem ist ein intervall von 1er minute schon sehr gering...
du solltest eher ein anderes system versuchen
zb. jede minute zwar aufrufen, aber nur eintragen, wenn ein user online geht und wenn er offline geht, dann hast du schätzomativ 0,1% der jetzigen daten

nein, hab keinen primkey. wofür ist der überhaupt? es ist schon sinnvoll, jede min zu speichern, da ich ja auch die koords mitspeichere und somit nachvollziehen kann, wer wann wo war.

hmm, gemeinsamer index, ich hab beim anlegen einfach bei beiden das hackerl für index gemacht, hat dann wohl nen gemiensamen angelegt.

was ich vielelicht auch vergessen habe, es wird meisten nach der zeit sortiert, manchmal auch gruppiert, immer aber eigentlich desc.

tia

thx
daß dieser table viel platz brauchen wird, ist mir klar. nur versuche ich halt nach möglichkeit ihn zu verkleinern, da ich dann die daten länger speichern kann.

die map ist 6144x4096 groß. ich überlege noch, ob ich nicht vielleicht jeweils eine fläche von 2x2 oder 4x4 oder gar 5x5 zusammenziehe, da ich das pic der map eh verkleinern muß, damit mans im browser ansehen kann mit den punkten drauf, wo wer ist. selbst wenn ich eine 4x4 fläche nehme, ist es immer noch 1536x1024 groß, was zu 1572864 einträgen im hilfstable führen würde. zahlt sich das aus, ist join so flott? und wie sollte die hilfstablle aussehen? id, x, y? id dann autoincrement, unique und primärschlüssel? aber würde das überhaupt eine platzeinsparung bedueten? ich hab zwar jetzt nur eine spalte im haupttable, dafür muß ich aber einen größeren zahlenbreich nehmen. mit smallint ist da nix mehr, da geht sich nicht grad mal mit mediumint aus.

MIK

also, entgegen dem was seppo meint wäre die _meine_ lösung die, dass du in der main-table den sessions einen primary key mitgibst

dh.
sessions [sid(primary),cid,start,stop]
waypoints [sid(key),x,y]

ausserdem kannst du dann datensätze "sparen" indem du nichts einträgst wenn der char sich garnicht bewegt hat, die positionen sind dann noch immer eindeutig - in dem fall müsstest du aber den timestamp hinzufügen, um die route auch zeitlich verfolgen zu können - da wäre halt die frage mit der erfahrung, wird mehr gereist oder mehr gestanden/crafted/wwi
weiters ist ein simpler join nicht sehr aufwändig, es sind ja nur zwei tables
weiters wirst du wahrscheinlich viel mehr inserts machen als selects(joins)

würd glaub ich auch gehn, aber wenn die beiden spalten oft abgefragt werden dann is über index schneller

Zitat von kleinerChemiker

@watchout: da man sich meistens mehr bewegt, als herumgestanden wird, würde das nicht allzuviel einspaarung bringen. es geht vor allem um eine nicht zu große belstung des db-servers bzw. geschwindigkeit. umso weniger platz ich pro tag verbrauche, umso länger kann ich die daten speichern. aber länger als 6monate hab ich eh nciht vor, die detailierten stats zu speichern.
wenn ich nur positionsänderungen speichere, erspare ich mir vielleicht etwas speicherplatz, habe dafür dann aber mehr aufwand mit php.

daher werde ich wohl bei charid, timestamp, x, y bleiben und nen index auf charid und timestamp legen. da hoffe ich dann mit etwa 1mb pro tag wegzukommen.

thx

MIK

@seppo, jetzt willst mir aber net sagen dass der timestamp unique is

@chemiker
tja wie du willst

hmm hab ich was falsch verstanden ?

wenn er nur charid in primkey nimmt und von jeder charid 1 mal pro minute ein eintrag kommt.. hauts die db auf.. weil dupletten

also muss er timestamp dazunehmen!

oder bin ich jetzt nur confused