[danjel]

Hej!

Har lite problem med prestanda eller egentligen en allmän fundering kring denna typ av mysql frågor.
Nedanstående ska helt enkelt ta ut de 10 som senast har loggat in på ett system (tabellen inloggs ) och visa upp deras medlemsnamn som finns i en annan tabell (member)

SELECT
inloggs.*, member.user_name
FROM
inloggs, member
WHERE
inloggs.user_id=member.user_id
ORDER BY inloggs.id DESC
LIMIT 0,10

Denna tar ca 0.7 sekunder att exekvera,vilket i och för sig är godtagbart just nu men då innehåller inloggstabellen 120000 rader och members ca 6000 rader, inte speciellt mycket alltså....
(inloggs.user_id och member.user_id är indexerade, inloggs.id är auto increment)

Denna fråga går att optimera så här:

SELECT
inloggs.*, member.user_name
FROM
inloggs, member
WHERE
inloggs.user_id=member.user_id
AND inloggs.id > 119990
ORDER BY inloggs.id DESC
LIMIT 0,10


Alltså man hämtar först ut max värde för id och drar ifrån 10 , men det känns lite omständigt att behöva en extra query för detta..hur kan man annars göra ..någon som vet..?

[Anders]

Originally posted by danjel@Nov 24 2003, 16:29
Alltså man hämtar först ut max värde för id och drar ifrån 10 , men det känns lite omständigt att behöva en extra query för detta..hur kan man annars göra ..någon som vet..?

Ta och kolla lite på HAVING.
http://www.mysql.com/doc/en/SELECT.html
Eftersom du kan ha både HAVING och WHERE så borde det går i samma query. Sen kan du ju kolla lite på LEFT JOIN och UNION.

[Tobbe]

Tror du ska ta dig en titt på JOINs...

[ZN]

Observera att UNION inte stöds i versioner äldre än 4.

[danjel]

Tack för era synpunkter. Kör inte mySQL 4 så varken union eller subqueries kan användas dessvärre...
Jag kan få det att funka med having men då tar det ca 4 sekunder :huh:

[Anders]

Ursprungligen postat av danjel

Tack för era synpunkter. Kör inte mySQL 4 så varken union eller subqueries kan användas dessvärre...
Jag kan få det att funka med having men då tar det ca 4 sekunder :huh:

Ok, hur lång tid tar det med JOIN då? Då kan du ju köra två frågor "samtidigt"...

Ursprungligen postat av danjel

Nedanstående ska helt enkelt ta ut de 10 som senast har loggat in på ett system (tabellen inloggs ) och visa upp deras medlemsnamn som finns i en annan tabell (member)
[...]
då innehåller inloggstabellen 120000 rader och members ca 6000 rader [...]

Du kan inte rensa tabellen inloggs nån gång då och då? Detta snabbar ju upp sökningen då det inte är lika mycket data som ska sökas igenom. Dessutom kan du:
* istället för att skriva LIMIT 0,10 skriva bara LIMIT 10
* istället för att hämta inloggs.* bara hämta de fält du behöver; inloggs.user_id
Dessa två punkter gör inte så mycket, men sen när det blir ännu mer kommer det synas mer.

[danjel]

Tack för sypunkterna lunne..

Ok, hur lång tid tar det med JOIN då? Då kan du ju köra två frågor "samtidigt"...

..osäker på vad du menar, frågan använder ju redan en join..?

Ja att rensa tabellen,det har du rätt i, man bör nog rensa den rätt ofta...

Får ner det till 0.5 sekunder som bäst..
men boven i dramat är ORDER BY har jag märkt,
tar jag bort den tar frågan ca 0.025 sekunder...

[Anders]

Ursprungligen postat av danjel

Tack för sypunkterna lunne..

Så lite så, tycker ju det är intressant med optimering...

Originally posted by -danjel@Nov 27 2003, 16:02

..osäker på vad du menar, frågan använder ju redan en join..?

Jo, det var bara en tanke. Men jag tycker inte det blir riktigt rätt sätt att använda JOIN på, skit i det. Skulle dessutom vara slött...

Originally posted by -danjel@Nov 27 2003, 16:02
Ja att rensa tabellen,det har du rätt i, man bör nog rensa den rätt ofta...

Jo, behöver du datan någon annanstans, eller går det sammanfatta i en annan tabell?

Ursprungligen postat av danjel

Får ner det till 0.5 sekunder som bäst..
men boven i dramat är ORDER BY har jag märkt,
tar jag bort den tar frågan ca 0.025 sekunder...

Jo, men är det noga vem av de 10 som loggade in sist?

[clindh]

Problemet tror jag är att du gör en descending order by - testa att sortera åt andra hållet och se om det hjälper. Med ditt lilla urval kan du ju alltid vända på ID:na i minnet sedan eller iterera resultatet baklänges.

I MySQL 4 skall det finnas ett sätt att bygga index så att de istället ordnas descending - men jag vet inte exakt hur...

[Anders]

Originally posted by clindh@Dec 1 2003, 12:09
Problemet tror jag är att du gör en descending order by - testa att sortera åt andra hållet och se om det hjälper. Med ditt lilla urval kan du ju alltid vända på ID:na i minnet sedan eller iterera resultatet baklänges.

Man tjänar sällan något på att sortera efter man fått ut datan från databasen, för MySQL i detta fall, är rätt snabb på det. Min erfarenhet säger mig att ASP och PHP är minst lika "slöa" på att sortera. Men man kan ju alltid prova.