FAQ |
Kalender |
![]() |
#27 | ||
|
|||
Klarade millennium-buggen
|
Citat:
Jag gjorde om den till en SP och då droppade exekveringstiden till 16 ms. Jag testade även att lägga till genre 10 för att testa med 3 och det var exakt samma exekveringstid på 16 ms. Jag kör ett gammalt tröskverk som Lenovo Thinkpad T410 på 2,4 GHz och prestanda 4,2 enligt MinDator.System.... Noterat är att när jag körde USE på databasen så tog det också 15-16 ms. Det är en överdriven rädsla at använda Subquerys för är inte alls så prestandakrävande som det påstås. Blir det en flaskhals får man väl ta det problemet då, men SQL-Engine gör sina egna optimeringar och i synnerhet om man gör om frågan till en SP. Prestandamässigt vinner man oftast mer på att ha rätt index. Men visst, jag förnekar inte tat en JOIN kan vara snabbare, men frågan är hur många år man måste köra applikationen innan optimeringsjobbet lönar sig.... Prestandaförlusten i det här fallet borde helt enkelt vara omärkbar för användaren. Om man optimerar frågan ner till 0 så kan man inte vinna mer än 16 ms .... men användaren kommer inte att märka någon skillnad ändå, för det tar längre tid att tanka ner webbsidan som visar resultatet.... Kod:
-- -------------------------------------------------------------------------------- -- Routine DDL -- Note: comments before and after the routine body will not be stored by the server -- -------------------------------------------------------------------------------- DELIMITER $$ CREATE DEFINER=`root`@`localhost` PROCEDURE `getMoviesShowAllGenres`() BEGIN SELECT q1.id, q1.date, group_concat(genres.name) genre_field FROM ( SELECT m.id, m.date FROM movies m JOIN movie_genres mg ON mg.movie_id = m.id AND mg.genre_id IN (1, 11) GROUP BY m.id HAVING COUNT(DISTINCT mg.genre_id) = 2 ) q1 JOIN movie_genres mg on mg.movie_id = q1.id JOIN genres ON mg.genre_id = genres.id GROUP BY q1.id ORDER BY q1.date ASC ; END Senast redigerad av Conny Westh den 2013-06-24 klockan 17:13 |
||
![]() |
![]() |
|
|