Het lijdt geen twijfel dat versie 1 - apart waar clausules aan elke kant van de vakbond - sneller zal zijn. Laten we eens kijken waarom de versie - waar de clausule over het vakbondsresultaat - slechter is:
- gegevensvolume:er zullen altijd meer rijen in het samenvoegingsresultaat zijn, omdat er minder voorwaarden zijn voor welke rijen worden geretourneerd. Dit betekent meer schijf-I/O (afhankelijk van indexen), meer tijdelijke opslag voor de rijenset, wat meer verwerkingstijd betekent
- herhaalde scan:het volledige resultaat van de unie moet opnieuw worden gescand om de voorwaarde toe te passen, terwijl deze tijdens de eerste scan had kunnen worden afgehandeld. Dit betekent dat de rijenset dubbel moet worden afgehandeld, hoewel waarschijnlijk in het geheugen, maar toch is het extra werk.
- indexen worden niet gebruikt voor where-clausules op een unieresultaat. Als u een index heeft over de velden voor refererende sleutels en postType, het zou niet worden gebruikt
Als je maximale prestaties wilt, gebruik dan UNION ALL , die de rijen rechtstreeks in het resultaat doorgeeft zonder overhead, in plaats van UNION , die duplicaten verwijdert (meestal door te sorteren) en duur kan zijn en onnodig is op basis van uw opmerkingen
Definieer deze indexen en gebruik versie 1 voor maximale prestaties:
create index t1_authorID_postType on t1(authorID, postType);
create index t1_websiteID_postType on t1(websiteID, postType);