Schrift
[thread]3463[/thread]

Effiziente SELECTs in MySQL: Insertion order determinieren? (Seite 3)



<< |< 1 2 3 >| >> 24 Einträge, 3 Seiten
ptk
 2004-06-09 15:32
#32234 #32234
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
[quote=Oesi50,09.06.2004, 12:10]was gibt das?

explain select accesslog_id from accesslog where int_time >1080770400 LIMIT 0,1;

und wie lange dauert es?

Wenn die Spalte einen Index hat, geht es auch ohne ORDER BY[/quote]
Heisst das, dass die Reihenfolge des Ergebnisses zugesichert ist, wenn ein Index existiert? Das wuerde mir in der Tat helfen.
Oesi50
 2004-06-09 15:57
#32235 #32235
User since
2004-05-15
33 Artikel
BenutzerIn
[default_avatar]
Quote
Heisst das, dass die Reihenfolge des Ergebnisses zugesichert ist, wenn ein Index existiert? Das wuerde mir in der Tat helfen.


Ja so ist es.

[EDIT]das stimmt so nur mit der indizierten Spalte[/EDIT]

mich wundern aber Deine Ergebnisse. Überprüfe noch mal, ob dein Index wirklich richtig ist.\n\n

<!--EDIT|Oesi50|1086783186-->
ptk
 2004-06-09 16:18
#32236 #32236
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
[quote=Oesi50,09.06.2004, 13:57]
Quote
Heisst das, dass die Reihenfolge des Ergebnisses zugesichert ist, wenn ein Index existiert? Das wuerde mir in der Tat helfen.


Ja so ist es.

[EDIT]das stimmt so nur mit der indizierten Spalte[/EDIT]
[/quote]Ich habe viele indizierten Spalten. Gewinnt der primary key? Hast du eine Referenz dazu?
Quote
mich wundern aber Deine Ergebnisse. Überprüfe noch mal, ob dein Index wirklich richtig ist.

Die Tabellendefinition sieht so aus:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
+--------------+------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------------------+----------------+
| accesslog_id | int(10) unsigned | | PRI | NULL | auto_increment |
| host | varchar(255) | | | | |
| user | varchar(255) | YES | MUL | NULL | |
| accessdate | datetime | | MUL | 0000-00-00 00:00:00 | |
| rtype | varchar(10) | | | | |
| file | varchar(255) | | MUL | | |
| querystring | text | YES | | NULL | |
| proto | varchar(8) | | | | |
| code | int(10) unsigned | | MUL | 0 | |
| bytes | int(10) unsigned | | | 0 | |
| refer | varchar(255) | YES | | NULL | |
| agent | varchar(255) | YES | MUL | NULL | |
| provider | int(10) unsigned | YES | MUL | NULL | |
| id | varchar(255) | YES | MUL | NULL | |
| int_time | int(11) | YES | MUL | NULL | |
+--------------+------------------+------+-----+---------------------+----------------+

In http://dev.mysql.com/doc/mysql/en/ORDER_BY_optimisation.html sind die Faelle beschrieben, wo ORDER BY nicht optimiert werden kann. Am naechsten zu meinem Problem ist folgendes:
Quote
You use ORDER BY on non-consecutive key parts:

SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;
Oesi50
 2004-06-09 16:36
#32237 #32237
User since
2004-05-15
33 Artikel
BenutzerIn
[default_avatar]
Hier mal meine Optimierungstips für Dich

1. Alle Spalten mit NOT NULL definieren.
2. acces_time als TIMESTAMP
3. einen UNIQUE Index über access_time UND access_id anlegen
4. SELECT SQL_SMALL_RESULT ..... LIMIT 1

mit dieser Struktur
Code: (dl )
1
2
3
4
5
6
7
8
9
CREATE TABLE 1_ticklist (
id int(10) unsigned NOT NULL auto_increment,
sym char(5) NOT NULL default '',
zeit timestamp(14) NOT NULL,
kurs mediumint(8) unsigned NOT NULL default '0',
volumen mediumint(8) unsigned NOT NULL default '0',
PRIMARY KEY (id),
KEY zeitid (zeit,id)
) TYPE=MyISAM PACK_KEYS=1 COMMENT='Tickerliste';


und dieser Abfrage
Code: (dl )
1
2
3
4
select SQL_SMALL_RESULT min(id)
from 1_ticklist
where zeit > '2004-06-08 00:00:00'
LIMIT 0,1;


erhalte ich die besten Ergebnisse. Das sind zwar zur Zeit nur 179087 Zeilen, aber die Tendenz ist doch schon eindeutig.\n\n

<!--EDIT|Oesi50|1086793261-->
<< |< 1 2 3 >| >> 24 Einträge, 3 Seiten



View all threads created 2004-06-08 16:02.