mysql: index oder nicht index

Seite 1 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/mysql_index_oder_nicht_index_126571/page_1 - zur Vollversion wechseln!

kleinerChemiker schrieb am 07.10.2004 um 20:11

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

Wannabe2k schrieb am 07.10.2004 um 21:27

in oracle gibs so was wie index organisierte tabellen, dh du host keine eigene indextabelle sondern index und datensätze liegen in der gleichen tabelle; jedoch kannst dann mehr nicht über row id zugreifen;
nur weiß ich jetzt leider nicht obs mit mysql auch geht

oder bitmap index sollte auch helfen platz zu sparen (wenn ich jetzt richtig lieg)

watchout schrieb am 08.10.2004 um 01:26

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

Seppo schrieb am 08.10.2004 um 12:48

Zitat von watchout
sorry, aber imho is' da ein kleiner fehler im index...

warum sollte es ein fehler sein ?
es is nur irgendwie nicht sinnvoll

in deinem fall wärd ich index löschen aber eine zeilenid als primärschlussel anlegen

seh ich das so richtig das du derzeit gar keinen primkey hast ? :confused:

kleinerChemiker schrieb am 08.10.2004 um 15:20

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

watchout schrieb am 08.10.2004 um 15:39

Zitat von kleinerChemiker
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

also, die grösse des index kommt imho daher, dass du einen über 2 felder gemacht hast, wenn du für jede der spalten einzeln machst müsste er kleiner sein (da du keine relationen mehr hast)

wenn du unbedingt die koordinaten haben willst solltest du dir vielleicht überlegen eine eigene table dafür anzulegen
primary key brauchst eigentlich nicht in deinem anwendungsfall, der is nur gut, wenn du nach einem einzelnen datensatz suchen willst, wie zb. hier im forum die postid is ein primary key

@seppo, ich meinte natürlich designfehler.. :rolleyes:

kleinerChemiker schrieb am 08.10.2004 um 15:53

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

Seppo schrieb am 08.10.2004 um 17:19

sorry muss mich auch noch mal kurz wichtig machen :P

ein primkey ist etwas eindeutiges ... dh. es kann innerhalb des primkey keine dupletten geben ...

ausserdem erleichtert dir ein primkey bei großen DBs eine auswertung, weil du einfach einen schnelleren zugriff hast wenn du bei deinem select befehl in der where bedingung den primkey mitgibst...

edit: ähm ja wenn du mit hilfstable machst würd ich als primkey die zeilenid mit autoincrement und x eine spalte und y eine spalte!

edit: was codest du da eigentlich.. kann man das wo begutachten ? :rolleyes:

watchout schrieb am 08.10.2004 um 18:04

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)

Seppo schrieb am 08.10.2004 um 18:42

uhmm.. was meine ich denn ?

eigentlich müssts doch auch gehen in dem ers so lasst und einfach den index löscht und dafür char + timestamp in primkey aufnimmt oder ?

Wannabe2k schrieb am 08.10.2004 um 19:15

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

kleinerChemiker schrieb am 08.10.2004 um 19:27

@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

watchout schrieb am 09.10.2004 um 00:25

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

Silvasurfer schrieb am 09.10.2004 um 00:37

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

@chemiker
tja wie du willst

nicht wenn die zeitverschiebung in den nächsten wochen kommt =)

Seppo schrieb am 09.10.2004 um 01:49

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 :confused: