Snabba upp join

har en JOIN som tar alldeles för lång tid på sig. Det är en kompis som har skrivit queryn och koden omkring det, så jag har inte kollat så noga på det än, men går det att snabba upp en join genom att indexera, och isf hur mycket prestandaskillnad rör det sig om?

Queryn tar i dagsläget ibland över 60 sekunder. Den tiden borde ligga omkring 5-10 sek max.

Kanske finns andra snabbare alternativ till JOINS?

går det att snabba upp en join genom att indexera

Ja, indexera de kolumner som används i jämförelsen i båda tabellerna. Det kan även vara relevant att indexera andra kolumner, det beror på vilka icke join villkor du har.

Kanske finns andra snabbare alternativ till JOINS?

Nej.

60 sekunder

Är det en enormt stor databas ?
Är det själva databasen som tar 60 sekunder på sig eller hela sidan?

Kolla upp din kod lite också.

Re: Snabba upp join

ps skrev:

har en JOIN som tar alldeles för lång tid på sig. Det är en kompis som har skrivit queryn och koden omkring det, så jag har inte kollat så noga på det än, men går det att snabba upp en join genom att indexera, och isf hur mycket prestandaskillnad rör det sig om?

Queryn tar i dagsläget ibland över 60 sekunder. Den tiden borde ligga omkring 5-10 sek max....

Det beror ju lite på hur den är skriven. Om du begränsar den så mycket det går i själva joinen kan den inte göras snabbare, men om du skapar en full kryssprodukt först och begränsar den sedan kan det ta onödigt lång tid att skapa den. Å andra sidan borde väl optimeraren upptäcka det?

Okej, ska kika lite mer på det här med att indexera med andra ord :)

Är det en enormt stor databas ?
Är det själva databasen som tar 60 sekunder på sig eller hela sidan?

Det är själva queryn som tar ca 60 s.
Det är 2 tabeller som ska joinas. det är ca 500 rader i den ena och 4000 i den andra.

Ser ut i stil med:

SELECT a.id, a.name, a.category_id, a.realprogress, a.estimated, SUM(r.time)  AS time, a.hasprogress 
FROM activity a 
LEFT  OUTER  JOIN reportedtime r ON a.id = r.activity_id 
GROUP  BY a.id 
ORDER  BY a.category_id, a.name

ps skrev:

... Ser ut i stil med:

SELECT a.id, a.name, a.category_id, a.realprogress, a.estimated,
              SUM(r.time)  AS time, a.hasprogress 
FROM activity a 
LEFT  OUTER  JOIN reportedtime r ON a.id = r.activity_id 
GROUP  BY a.id 
ORDER  BY a.category_id, a.name

OK, jag kan vara helt och hållet ute och cykla... men jag tycker att ovanstående kod ser skum ut. Dina namn leder till mitt antagande att a.id är ett unikt nr i tabellen activity. Stämmer det?

GROUP BY samlar ihop all info som har samma activity_id i reportedtime "buntvis" - eftersom det är = a.id. Hur många rader finns det i reportedtime som har samma activity_id? Är det också unikt, vilket namnet antyder? I så fall görs en massa onödigt jobb!

OM a.id och r.activity_id är unika tal i sina respektive relationer ==> GROUP BY kommer att för varje värde på a.id att få ihop exakt en rad. ==> SUM(r.time) = r.time ==> GROUP BY tillför massor med jobb för ingenting. I så fall borde det stå:

SELECT a.id, a.name, a.category_id, a.realprogress, a.estimated, 
               r.time  AS time, a.hasprogress 
FROM activity a 
LEFT  OUTER  JOIN reportedtime r ON a.id = r.activity_id 
ORDER  BY a.category_id, a.name

vilket borde kunna gå snabbare.

a.id är unikt ja, men inte activity_id i den andra tabellen. activity_id används som foreign key. Det finns flera rader det är därför som tiden summeras.
GROUP BY måste vara med eftersom en SUM görs.

GROUP BY måste vara med eftersom en SUM görs

jepps, mysql brukar vilja ha group by när aggregatfunktioner används. Så i detta fallet borde det vara riktigt att gruppera på ett unikt fält. Jag kör liknande sql-frågor med fler antal poster, och det tar inga 60 sekunder, snarare 1 eller därunder. Visserligen vet jag inte hur mycket data dina fält innehåller. Det är lite vanskligt att jämföra så, men, men...