Nie ma wątpliwości, że wersja 1 - oddzielne klauzule gdzie po każdej stronie unii - będzie szybsza. Przyjrzyjmy się, dlaczego wersja — gdzie klauzula nad wynikiem związku — jest gorsza:
- Ilość danych:zawsze będzie więcej wierszy w wyniku sumy, ponieważ jest mniej warunków dotyczących zwracanych wierszy. Oznacza to więcej dyskowych operacji we/wy (w zależności od indeksów), więcej tymczasowej pamięci do przechowywania zestawu wierszy, co oznacza dłuższy czas przetwarzania
- powtarzane skanowanie:cały wynik łączenia musi zostać ponownie przeskanowany, aby zastosować warunek, gdy mógł zostać obsłużony podczas początkowego skanowania. Oznacza to podwójną obsługę zestawu wierszy, choć prawdopodobnie w pamięci, ale nadal jest to dodatkowa praca.
- indeksy nie są używane dla klauzul where w wyniku sumy. Jeśli masz indeks nad polami kluczy obcych i postType, nie będzie używany
Jeśli chcesz maksymalnej wydajności, użyj UNION ALL , który przekazuje wiersze bezpośrednio do wyniku bez narzutu, zamiast UNION , który usuwa duplikaty (zwykle przez sortowanie) i może być kosztowny i jest niepotrzebny na podstawie Twoich komentarzy
Zdefiniuj te indeksy i użyj wersji 1, aby uzyskać maksymalną wydajność:
create index t1_authorID_postType on t1(authorID, postType);
create index t1_websiteID_postType on t1(websiteID, postType);
