[Conth]

Hittar inte svaret/anledningen till detta beteende.
Jag gör en sökning i databasen med limit och order by
Jag har ett index som matcher order by-villkoret (hdshop,hdcolor) som väljs om jag kör explain)

Jag förväntar mig att inte alla rader behöver komma med på examined när jag ska hämta ett intervall av rader vid sökning?! Tycker det borde räcka att använda indexet?! Har jag fattat det hela fel eller är det någon som kan förklara detta?!

Jag kör mysql 5.0.16 på linux.

Från slow-loggen:
# Query_time: 23 Lock_time: 0 Rows_sent: 30 Rows_examined: 72520
SELECT * FROM hdsearch where hdshop = 1 order by hdshop, hdcolor limit 72490, 30;

[WizKid]

Hur ser EXPLAIN ut för den queryn?

[Conth]

Den visar att indexet används men att rows är högt:

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE hdsearch ref PRIMARY,base,color color 12 const,const 44411 Using where


Vet inte varför rows blir 44411...!?

[kullervo]

Ibland är det snabbare att skita i index. T.ex. du har 1000 rader i en tabell där 990 av dem har samma specifika värde i en indexerad kolumn. Om du vill hämta ut alla rader som har detta specifika värde i just den kolumnen så är det ju onekerligen snabbare att skita i indexet.

Förövrigt är det bara att acceptera att MySQL gör tokiga saker och att det finns en del prestandabuggar.

[WizKid]

Antagligen beror det på att det är väldigt många av raderna som har hdshop = 1. Frågan är om det skulle vara snabbare att köra:
SELECT * FROM hdsearch where hdshop = 1 order by hdcolor limit 72490, 30;
och ha ett index på hdcolor. Möjligtvis även tvinga MySQL till att använda hdcolor-indexet så att den inte använder någon index för hdshop.

[Conth]

Originally posted by WizKid@Jun 9 2006, 16:06
Antagligen beror det på att det är väldigt många av raderna som har hdshop = 1. Frågan är om det skulle vara snabbare att köra:
SELECT * FROM hdsearch where hdshop = 1 order by hdcolor limit 72490, 30;
och ha ett index på hdcolor. Möjligtvis även tvinga MySQL till att använda hdcolor-indexet så att den inte använder någon index för hdshop.

Ska testa det. Fattar ändå inte varför indexet inte "biter"...

Ibland är det snabbare att skita i index. T.ex. du har 1000 rader i en tabell där 990 av dem har samma specifika värde i en indexerad kolumn. Om du vill hämta ut alla rader som har detta specifika värde i just den kolumnen så är det ju onekerligen snabbare att skita i indexet.

Så är det inte i detta fallet.

Förövrigt är det bara att acceptera att MySQL gör tokiga saker och att det finns en del prestandabuggar

Förvisso - men detta känns väl ändå som en rätt basic-grej!?!? Att använda befintligt index isf table scan - eller missar jag något. Någon som har sett samma fenomen??

[grazzy]

Jag har sett lite liknande konstigheter vid joins tidigare.. men har då avskrivit det som fel jag skulle ha gjort.. sen har jag beställt snabbare servrar och slutat tänka på det hela..