Det råder ingen tvekan om att version 1 – separat där klausuler på varje sida av förbundet – kommer att vara snabbare. Låt oss titta på varför version - där klausul över det fackliga resultatet - är sämre:
- datavolym:det kommer alltid att finnas fler rader i unionsresultatet, eftersom det finns mindre villkor för vilka rader som returneras. Detta innebär mer disk I/O (beroende på index), mer temporär lagring för att hålla raduppsättningen, vilket innebär mer bearbetningstid
- upprepad skanning:hela resultatet av föreningen måste skannas igen för att tillämpa villkoret, när det kunde ha hanterats under den första skanningen. Detta innebär dubbel hantering av raduppsättningen, om än förmodligen i minnet, men det är ändå extraarbete.
- index används inte för where-klausuler på ett fackligt resultat. Om du har ett index över främmande nyckelfälten och postType, skulle den inte användas
Om du vill ha maximal prestanda, använd UNION ALL , som skickar raderna rakt ut i resultatet utan overhead, istället för UNION , som tar bort dubbletter (vanligtvis genom sortering) och kan vara dyrt och är onödigt baserat i dina kommentarer
Definiera dessa index och använd version 1 för maximal prestanda:
create index t1_authorID_postType on t1(authorID, postType);
create index t1_websiteID_postType on t1(websiteID, postType);