kostenloser Webspace werbefrei: lima-city

MySQL Datenbankabfrage und Idizes

lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess

1. Autor dieses Themas

   t**k

   22:49, 21.4.2013

   Hey allerseits,
   
   zur Zeit bin ich dabei, eine Datenbanktabelle zu entwerfen zum speichern von Chatnachrichten, bis jetzt sieht das so aus:
   

   CREATE TABLE `messages` (
     `int_msgid` int(10) unsigned NOT NULL AUTO_INCREMENT,
     `int_senderid` int(10) unsigned NOT NULL,
     `int_receiverid` int(10) unsigned NOT NULL,
     `str_message` text NOT NULL,
     `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
     PRIMARY KEY (`int_msgid`),
     KEY `int_senderid` (`int_senderid`,`int_receiverid`)
   ) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

   
   
   Abgefragt wird mit dem Query:
   

   SELECT int_msgid, int_senderid, int_receiverid, str_message, UNIX_TIMESTAMP(timestamp) AS int_timestamp
   FROM messages
   WHERE ((int_senderid = [id_logged-in] AND int_receiverid = [id_partner]) OR (int_senderid = [id_partner] AND int_receiverid = [id_logged-in]))
   AND int_msgid > [id_lastmsg]
   ORDER BY int_msgid

   
   
   Leider zeigt ein EXPLAIN:
   

   id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
   1	SIMPLE	messages	ALL	PRIMARY,int_senderid	NULL	NULL	NULL	11	Using where; Using filesort

   
   Also wird kein Index genutzt und er geht alle Datensätze durch, was im Moment zwar ginge, aber auf Dauer sehr ineffizient wäre.
   
   Daher meine Frage, ob jemand von euch eine Idee hätte, wie ich den Query, die Tabellenstruktur oder die Indizes anpassen müsste, damit es einen der Indizes nutzt.
   
   Ich weiß, dass wenn man die eine OR Bedingung weglässt, dass es dann den Index nutzt, aber dann holt er auch nicht alle Nachrichten ab.
   

2. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

   lima-city: Gratis werbefreier Webspace für deine eigene Homepage

3. chatter

   

   chatter hat kostenlosen Webspace.

   0:09, 22.4.2013

   Befüll die DB mal etwas. Es kann durchaus sein, dass MySQL einen kompletten Tabellenscan als schneller erachtet, als den Index zu benutzen. Das ändert sich meist mit genügend Datensätzen.
4. Autor dieses Themas

   t**k

   12:28, 22.4.2013

   chatter schrieb:
   Befüll die DB mal etwas. Es kann durchaus sein, dass MySQL einen kompletten Tabellenscan als schneller erachtet, als den Index zu benutzen. Das ändert sich meist mit genügend Datensätzen.

   
   OK, habe jetzt gut 6,5 Millionen Enträge in der Datenbank.
   
   Jedoch benutzt er für manche Abfragen keinen Key:
   

   id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
   1	SIMPLE	messages	ALL	PRIMARY,int_senderid	NULL	NULL	NULL	6508798	Using where; Using filesort

   
   (ca. 1,3 Millionen Ergebnisse => fast 8 Sekunden)
   
   Und für andere schon:
   

   id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
   1	SIMPLE	messages	range	PRIMARY,int_senderid	int_senderid	8	NULL	4	Using where; Using filesort

   
   (6 Ergebnisse)
   
   Ich glaube ich muss das mal mit einem Zufallsgenerator befüllen...
   
   Wenn ich beim ersten Messen aktivierve erscheint aber soetwas:
   

   Sorting result	2.251374
   Sending data	5.669850

   
   Heißt das für mich, dass der Query nicht direkt das Problem ist, sondern die Zeit zum sortieren und senden?
   
   Mir war da auch eine Lösung jetzt eingefallen, weil im normalfall braucht man ja eigentlich nicht alle Daten: Gibt es die Möglichkeit mit LIMIT von hinten auszuzählen?

5. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

   lima-city: Gratis werbefreier Webspace für deine eigene Homepage

Dir gefällt dieses Thema?