---

Jeg har en table irclog der er sat op på denne måde (sql dump af structure)

CREATE TABLE irclog (
id int(9) NOT NULL auto_increment,
nick varchar(30) NOT NULL default '',
tekst text NOT NULL,
tid time NOT NULL default '00:00:00',
PRIMARY KEY (id),
UNIQUE KEY id (id),
UNIQUE KEY test (nick,tekst(100),tid),
KEY nick (nick),
KEY id_2 (id),
FULLTEXT KEY tekst (tekst)
) TYPE=MyISAM PACK_KEYS=1;

Jeg undrer mig over hastighederne på disse 3 typer forespørgsler

1: denne er hurtig hvilket den også burde være

select * from irclog order by id limit 1,5;

og giver 5 rows in set (0.00 sec)

2: Denne laver en fulltext search i mit text blob felt og matcher en streng
mod mit textfelt hvor nickname feltet er lig noget bestemt

select tid, nick, tekst, id from irclog where match (tekst) against ('det
har jeg aldrig sagt') having nick = 'hest' order by id limit 5;

en forholdsvis tung forespørgsel, men giver: 5 rows in set (0.06 sec)

3: Denne her undrer mig meget

select * from irclog order by id limit 234342,5;
Den skal blot vise 5 rækker fra rækkenummer 234342 men giver
5 rows in set (2.94 sec

3 sekunder ???

det er som om jo højere id nummeret er destro længere tid tager det, det
selvom id rækken er indexeret ?

dette er info på tabellen

TypeUsage
Data39,714KB
Index85,707KB
Total125,421KB


og

Row Statistic : StatementsValue
Formatdynamic
Rows837,839
Row length ø48
Row size ø153 Bytes
Next Autoindex837,840
CreationDec 30, 2004 at 05:05 PM
Last updateDec 30, 2004 at 05:10 PM
Last checkDec 30, 2004 at 05:13 PM


nogen der har et godt bud ?

- Tonny, www.jegergud.dk

---

> 3: Denne her undrer mig meget
>
> select * from irclog order by id limit 234342,5;
> Den skal blot vise 5 rækker fra rækkenummer 234342 men giver
> 5 rows in set (2.94 sec
>
> 3 sekunder ???
>
> det er som om jo højere id nummeret er destro længere tid tager det, det
> selvom id rækken er indexeret ?

Hvorfor har du den "order by ID"? Når den er indekseret skulle den gerne
komme ud sorteret på den måde automatisk...
Prøv at fjerne den order by, og se om den af en eller anden grund for DBMS
til ikke at kigge i indekset.

---

"Casper Bang" <webmaster_fjerndette@fjerndette_secretsofwar.net> skrev i en
meddelelse news:41d527a7$0$3887$edfadb0f@dread15.news.tele.dk...
>> 3: Denne her undrer mig meget
>>
>> select * from irclog order by id limit 234342,5;
>> Den skal blot vise 5 rækker fra rækkenummer 234342 men giver
>> 5 rows in set (2.94 sec
>>
>> 3 sekunder ???
>>
>> det er som om jo højere id nummeret er destro længere tid tager det, det
>> selvom id rækken er indexeret ?
>
> Hvorfor har du den "order by ID"? Når den er indekseret skulle den gerne
> komme ud sorteret på den måde automatisk...
> Prøv at fjerne den order by, og se om den af en eller anden grund for DBMS
> til ikke at kigge i indekset.
>

Det gjorde desværre ingen forskel

mysql> select * from irclog limit 834234,5;
+--------+-------+-------------------------+----------+
| id | nick | tekst | tid |
+--------+-------+-------------------------+----------+
| 834235 | JoFFe | Omid (Conzzept Records) | 01:26:00 |
| 834236 | poo | sku han ha heddet | 01:26:00 |
| 834237 | JoFFe | OMID OG PHILL!!! | 01:27:00 |
| 834238 | JoFFe | SÅ SKA JEG DA MED !! | 01:27:00 |
| 834239 | poo | slap af et israparty | 01:27:00 |
+--------+-------+-------------------------+----------+
5 rows in set (3.71 sec)

sammenlignet med

mysql> select * from irclog limit 1,5;
+----+-----------+-----------------------------------------------------------------------+----------+
| id | nick | tekst
| tid |
+----+-----------+-----------------------------------------------------------------------+----------+
| 2 | eXtreme` | where i can find root..
| 00:07:00 |
| 3 | kokanin | below trees
| 00:08:00 |
| 4 | kuffarpoo | <@propan-> andur_ryger_Sten.avi <- slap af med det der
rygeinstrument | 00:10:00 |
| 5 | kuffarpoo | [23:39:37] <@propan-> :)
| 00:10:00 |
| 6 | kuffarpoo | den er effektiv propan-
| 00:10:00 |
+----+-----------+-----------------------------------------------------------------------+----------+
5 rows in set (0.01 sec)

jeg smider lige en explain med for overskuelighedens skyld:

mysql> explain select * from irclog limit 1,5;
+--------+------+---------------+------+---------+------+--------+-------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+--------+------+---------------+------+---------+------+--------+-------+
| irclog | ALL | NULL | NULL | NULL | NULL | 837839 | |
+--------+------+---------------+------+---------+------+--------+-------+
1 row in set (0.00 sec)

mysql>

sammenlignet med:

mysql> explain select * from irclog limit 834234,5;
+--------+------+---------------+------+---------+------+--------+-------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+--------+------+---------------+------+---------+------+--------+-------+
| irclog | ALL | NULL | NULL | NULL | NULL | 837839 | |
+--------+------+---------------+------+---------+------+--------+-------+
1 row in set (0.00 sec)

mysql>

godt nytår forresten

- Tonny, www.jegergud.dk

---

> Det gjorde desværre ingen forskel

Hmm... jeg bruger ikke selv mySQL, så har desværre ikke en løsning til dig.
Det jeg får ud af det, er at den ikke bruger indexet - eller at din LIMIT
tager fat i hele tabellen på en eller anden måde.
Prøv med:
select * from irclog WHERE id => 834234 AND id <= 834239;

Nu jeg tænker over det, gør LIMIT nok at indexet ikke kan bruges, og den
derfor laver en linær søgning... den skal jo tælle alle records igennem, til
den når nummer 834234.
Med ovenstående bruger du til gengæld en direkte søgning, som burde være
hurtig. Problemet med ovenstående kommer dog hvis du ind imellem sletter en
record, så der kommer huller i dine IDer.

Fortæl os hvordan det går :)

---

"Casper Bang" <webmaster_fjerndette@fjerndette_secretsofwar.net> wrote in
message news:41d54dd6$0$67956$edfadb0f@dread15.news.tele.dk...
>> Det gjorde desværre ingen forskel
>
> Hmm... jeg bruger ikke selv mySQL, så har desværre ikke en løsning til
> dig.
> Det jeg får ud af det, er at den ikke bruger indexet - eller at din LIMIT
> tager fat i hele tabellen på en eller anden måde.
> Prøv med:
> select * from irclog WHERE id => 834234 AND id <= 834239;
>
> Nu jeg tænker over det, gør LIMIT nok at indexet ikke kan bruges, og den
> derfor laver en linær søgning... den skal jo tælle alle records igennem,
> til den når nummer 834234.
> Med ovenstående bruger du til gengæld en direkte søgning, som burde være
> hurtig. Problemet med ovenstående kommer dog hvis du ind imellem sletter
> en record, så der kommer huller i dine IDer.
>
> Fortæl os hvordan det går :)
>
mysql> select * from irclog WHERE id >= 834234 AND id <= 834239;
+--------+-------+--------------------------+----------+
| id | nick | tekst | tid |
+--------+-------+--------------------------+----------+
| 834234 | JoFFe | Phill (conzzept Records) | 01:26:00 |
| 834235 | JoFFe | Omid (Conzzept Records) | 01:26:00 |
| 834236 | poo | sku han ha heddet | 01:26:00 |
| 834237 | JoFFe | OMID OG PHILL!!! | 01:27:00 |
| 834238 | JoFFe | SÅ SKA JEG DA MED !! | 01:27:00 |
| 834239 | poo | slap af et israparty | 01:27:00 |
+--------+-------+--------------------------+----------+
6 rows in set (0.05 sec)

mysql>

det var noget bedre... det virker dog besynderligt at limit går udenom
index, så igen det var jo også hvad min explain sagde...

og nu siger den


mysql> explain select * from irclog WHERE id >= 834234 AND id <= 834239;
+--------+-------+-----------------+---------+---------+------+------+-------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra
|
+--------+-------+-----------------+---------+---------+------+------+-------------+
| irclog | range | PRIMARY,id,id_2 | PRIMARY | 4 | NULL | 4 | Using
where |
+--------+-------+-----------------+---------+---------+------+------+-------------+
1 row in set (0.00 sec)

mysql>

bemærk foriøvrigt at WHERE id => ikke virker men WHERE id >= virker fint go
figure...

tak for hjælpen.

- Tonny, www.jegergud.dk

---

> det var noget bedre... det virker dog besynderligt at limit går udenom
> index, så igen det var jo også hvad min explain sagde...

Tjaa, både og...
Når du bruger din LIMIT ved den ikke hvilken record den skal have fat i -
kun hvor mange der er FØR.
Se et B+ træ for dig - der er ikke noget der angiver i den enkelte knude,
hvor mange entries der er før. Derfor kan dit index ikke bruges.

LIMIT er nok ikke særligt smart at bruge, hvis man skal have fat i andet end
de X første records (i MS SQL hedder denne "TOP").


> bemærk foriøvrigt at WHERE id => ikke virker men WHERE id >= virker fint
> go figure...

Hmm, ja sådan er det vist også på MS SQL Server - i ASP kan den dog godt :p
Skal man lige tænke over.

Ha' et godt nytår.

---

Hej Casper
> Tjaa, både og...
> Når du bruger din LIMIT ved den ikke hvilken record den skal have fat i -
> kun hvor mange der er FØR.
> Se et B+ træ for dig - der er ikke noget der angiver i den enkelte knude,
> hvor mange entries der er før. Derfor kan dit index ikke bruges.

håber du havde et godt nytår.

kan du kort forklare hvad et B+ træ er ?

eller evt henvise mig til en side der forklarer det, det vil jeg gerne læse
lidt mere om.

- Tonny, www.jegergud.dk

---

On Sun, 02 Jan 2005 15:58:04 +0100, Tonny Jørgensen wrote:

> kan du kort forklare hvad et B+ træ er ?
>
> eller evt henvise mig til en side der forklarer det, det vil jeg gerne læse
> lidt mere om.

http://en.wikipedia.org/wiki/B_plus_tree

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

>> Tjaa, både og...
>> Når du bruger din LIMIT ved den ikke hvilken record den skal have fat i -
>> kun hvor mange der er FØR.
>> Se et B+ træ for dig - der er ikke noget der angiver i den enkelte knude,
>> hvor mange entries der er før. Derfor kan dit index ikke bruges.
>
> håber du havde et godt nytår.
>
> kan du kort forklare hvad et B+ træ er ?
>
> eller evt henvise mig til en side der forklarer det, det vil jeg gerne
> læse lidt mere om.

Troels giver et link, som beskriver det.

Men dybest set er B+træet dit index; ved hjælp af søgetræet kan rækkerne i
din tabel findes meget hurtigere.
Meget interessant, men nok ikke noget du vil få meget brug for i praksis;
din database opretter og vedligeholder selv træet.