Der er ingen tvivl om, at version 1 - separat hvor klausuler i hver side af fagforeningen - vil være hurtigere. Lad os se på, hvorfor version - hvor klausul over fagforeningsresultatet - er værre:
- datavolumen:der vil altid være flere rækker i unionsresultatet, fordi der er færre betingelser for, hvilke rækker der returneres. Dette betyder mere disk I/O (afhængigt af indekser), mere midlertidig lagerplads til at holde rækkesættet, hvilket betyder mere behandlingstid
- gentagen scanning:Hele resultatet af foreningen skal scannes igen for at anvende betingelsen, når den kunne have været håndteret under den indledende scanning. Dette betyder dobbelt håndtering af rækkesættet, omend sandsynligvis i hukommelsen, men det er stadig ekstra arbejde.
- indekser bruges ikke til where-klausuler på et unionsresultat. Hvis du har et indeks over fremmednøglefelterne og postType, ville det ikke blive brugt
Hvis du ønsker maksimal ydeevne, skal du bruge UNION ALL , som sender rækkerne lige ud i resultatet uden overhead, i stedet for UNION , som fjerner dubletter (normalt ved sortering) og kan være dyrt og er unødvendigt baseret i dine kommentarer
Definer disse indekser og brug version 1 for maksimal ydeevne:
create index t1_authorID_postType on t1(authorID, postType);
create index t1_websiteID_postType on t1(websiteID, postType);