GDZIE i JOIN kolejność operacji

Question

Moje pytanie jest podobne do tego SQL order of operations, ale z niewielkim akcentem, więc myślę, że to sprawiedliwe pytanie.

Używam Teradata. I mam 2 tabele: table1, table2.

table1 ma tylko kolumnę id.
table2 ma następujące kolumny: id, val

może się mylę, ale myślę, że te dwa stwierdzenia dają takie same wyniki.

komunikat 1.

SELECT table1.id, table2.val 
FROM table1 
INNER JOIN table2 
ON table1.id = table2.id 
WHERE table2.val<100 

komunikat 2.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT * 
    FROM table2 
    WHERE val<100 
) table3 
ON table1.id=table3.id 

Moje pytania to będzie optymalizator kwerendy być na tyle silny, aby
- wykonać WHERE najpierw przyłączyć później w oświadczeniu 1
- wiem, że tabela 3 nie jest rzeczywiście potrzebna w wyciągu 2

Jestem całkiem nowy w SQL, więc proszę, naucz mnie, jeśli coś nie rozumiem.

Answer 1

będzie to zależeć od wielu wielu rzeczy (rozmiar tabeli, indeksu, dystrybucji kluczy itp), należy po prostu sprawdzić plan wykonanie:

nie powiedzieć, który w bazie, ale oto kilka sposobów:
MySql EXPLAIN
SQL Server SET SHOWPLAN_ALL (Transact-SQL)
Oracle EXPLAIN PLAN

what is explain in teradata?
Teradata Capture and compare plans faster with Visual Explain and XML plan logging

Answer 2

O ile czegoś nie brakuje, dlaczego potrzebujesz Tabeli 1 ??

Wystarczy zapytać Table2

Select id, val 
From table2 
WHERE val<100 

lub używasz wiersze w tabela1 jako filtr? tj. Czy tabela 1 tylko kopntuje podzbiór identyfikatorów w tabeli 2?

Jeśli tak, to będzie działać, jak również ...

Select id, val 
From table2 
Where val<100 
    And id In (Select id 
       From table1) 

Ale odpowiedzi na swoje pytanie, optymalizator kwerendy Tak powinno być na tyle inteligentny, aby dowiedzieć się jak najlepszym porządku, w którym należy wykonać kroki niezbędne przetłumaczyć twoje logiczne instrukcje na wynik fizyczny. Używa strored statystyki, które bazy danych utrzymuje na każdej tabeli, aby ustalić, co robić (jaki rodzaj logiki łączenia do użycia na przykład), jak w porządku, jak kolejność wykonywania operacji w celu zminimalizowania IO dyskowych i kosztów przetwarzania.

Answer 3

Q1. wykonaj najpierw klauzulę WHERE, a następnie DOŁĄCZ później w Oświadczeniu 1

Chodzi o to, że jeśli zmienisz kolejność łączenia wewnętrznego, np. table2 INNER JOIN table1, to domyślnie klauzula WHERE może zostać przetworzona przed operacją JOIN, podczas fazy przygotowania .Sądzę jednak, że nawet jeśli nie zmienisz pierwotnego zapytania, optymalizator powinien mieć możliwość zmiany kolejności, jeśli uzna, że ​​operacja łączenia będzie zbyt kosztowna przy pobieraniu całego wiersza, więc najpierw zastosuje GDZIE. Tylko moje przypuszczenie.

Q2. wiem, że tabela 3 nie jest faktycznie potrzebna w Wyciągu 2

Teradata zinterpretuje twoje drugie zapytanie w taki sposób, że wyprowadzona tabela jest konieczna, więc będzie kontynuować przetwarzanie zaangażowanej tabeli 3.

Answer 4

zależności od dostępności danych statystycznych i indeksów dla tabel w pytaniu mechanizm przepisywania zapytań w Optimizer mogą lub nie mogą zdecydować się na skanowanie Table2 rekordy gdzie val < 100 przed skanowaniem Table1.

W niektórych sytuacjach, w oparciu o dane demograficzne, łączenia, indeksowanie i statystyki, może się okazać, że optymalizator nie eliminuje rekordów w planie kwerend, jeśli uważasz, że powinien. Nawet jeśli masz wyprowadzoną tabelę, taką jak ta w twoim przykładzie. Możesz zmusić optymalizator do przetworzenia wyprowadzonej tabeli, umieszczając GROUP BY w swojej wyprowadzonej tabeli. Optymalizator jest następnie zobowiązany do rozwiązania agregatu GROUP BY, zanim będzie mógł rozważyć rozwiązanie łączenia między dwiema tabelami w twoim przykładzie.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT table2.id, tabl2.val 
    FROM table2 
    WHERE val<100 
    GROUP BY 1,2 
) table3 
ON table1.id=table3.id 

Nie oznacza to, że standardowe podejście powinno polegać na tym, aby przejść przez ten kod. Jest to zazwyczaj jeden z moich ostatnich kurortów, gdy mam plan zapytań, który po prostu nie eliminuje zbędnych rekordów na tyle wcześnie w planie i powoduje, że zbyt wiele danych jest skanowanych i przenoszonych przez różne pliki SPOOL. Jest to po prostu technika, którą możesz umieścić w swoim pakiecie narzędzi, kiedy napotkasz taką sytuację.

Mechanizm przepisywania zapytań jest ciągle aktualizowany z jednego wydania do następnego, a szczegółowe informacje na temat jego działania można znaleźć w artykule SQL Transaction Processing Manual dotyczącym Teradata 13.0.