Powtarzam pytanie zadane przez Mongusa PongaDlaczego użycie tabeli tymczasowej byłoby szybsze niż zapytanie zagnieżdżone? który nie ma odpowiedzi, która działa dla mnie.

Większość z nas w pewnym momencie odkrywa, że ​​gdy zapytanie zagnieżdżone osiąga pewną złożoność, musi zostać podzielone na tabele tymczasowe, aby zachować jego wydajność. To jestabsurd że może to być najbardziej praktyczny krok naprzód i oznacza, że ​​procesy te nie mogą być już przekształcone w widok. I często aplikacje BI innych firm będą się dobrze bawić tylko z widokami, więc jest to kluczowe.

Jestem przekonany, że musi istnieć proste ustawienie zapytania, aby silnik po prostu buforował każde podzapytanie po kolei, działając od wewnątrz. Nie ma drugiego zgadywania, w jaki sposób może sprawić, że podzapytanie stanie się bardziej selektywne (co czasami robi to bardzo skutecznie) i nie ma możliwości skorelowania podzapytań. Tylko stos danych, które programista zamierzał zwrócić przez samodzielny kod między nawiasami.

Często zdarza mi się, że po prostu zmiana z podzapytania na #table zajmuje czas od 120 sekund do 5. Zasadniczo optymalizator popełnia gdzieś poważny błąd. Oczywiście, może być bardzo czasochłonny sposób, w jaki mogę zmusić optymalizatora do przyjrzenia się tabelom we właściwej kolejności, ale nawet to nie daje żadnych gwarancji. Nie pytam o idealny czas wykonywania 2 sekund tutaj, tylko prędkość, jaką zapewnia mi tempowanie, w ramach elastyczności awidok.

Nigdy wcześniej tutaj nie pisałem, ale od lat piszę SQL i czytałem komentarze innych doświadczonych ludzi, którzy właśnie zaakceptowali ten problem, a teraz chciałbym, aby odpowiedni geniusz wystąpił i powiedział specjalna wskazówka to X ...