WHERE và JOIN thứ tự hoạt động

Question

Câu hỏi của tôi tương tự như câu hỏi này SQL order of operations nhưng với một chút thay đổi, vì vậy tôi cho rằng công bằng là nên hỏi.

Tôi đang sử dụng Teradata. Và tôi có 2 bảng: table1, table2.

table1 chỉ có một cột id.
table2 có các cột sau: id, val

Tôi có thể sai nhưng tôi nghĩ rằng hai câu lệnh này cho kết quả tương tự.

Tuyên Bố 1.

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

Tuyên Bố 2.

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

Câu hỏi của tôi là, tôi ưu truy vấn sẽ đủ thông minh để
- thực thi mệnh đề WHERE đầu tiên sau đó THAM GIA sau này trong Bản Tuyên Bố 1
- biết rằng bảng 3 không thực sự cần thiết trong Bản khai 2

Tôi khá mới với SQL, vì vậy hãy giáo dục tôi nếu tôi hiểu nhầm bất cứ điều gì.

Answer 1

này sẽ phụ thuộc vào nhiều nhiều thứ (kích thước bảng, chỉ mục, phân phối chính, vv), bạn chỉ nên kiểm tra kế hoạch thực hiện:

bạn không nói trước với các cơ sở dữ liệu, nhưng đây là một số cách sau:
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

Trừ khi tôi thiếu thứ gì đó, Tại sao bạn thậm chí còn cần Table1 ??

Chỉ cần truy vấn Table2

Select id, val 
From table2 
WHERE val<100 

hoặc bạn đang sử dụng các hàng trong table1 như một bộ lọc? tức là, table1 chỉ copntain một tập hợp con của các Id trong Table2 ??

Nếu vậy, thì đây sẽ làm việc tốt ...

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

Nhưng để trả lời câu hỏi của bạn, Vâng tôi ưu truy vấn sẽ đủ thông minh để tìm ra thứ tự tốt nhất để thực hiện các bước cần thiết để dịch các chỉ dẫn logic của bạn thành một kết quả vật lý. Nó sử dụng số liệu thống kê mà cơ sở dữ liệu lưu trữ trên mỗi bảng để xác định việc cần làm (loại logic tham gia để sử dụng), như wekll như thứ tự để thực hiện các thao tác nhằm giảm thiểu tối đa các ổ đĩa và chi phí xử lý.

Answer 3

Q1. thực hiện mệnh đề WHERE trước, sau đó JOIN sau trong câu 1

Điều này là, nếu bạn chuyển đổi thứ tự của phép nối bên trong, tức là bảng 2 INNER JOIN table1, thì tôi đoán mệnh đề WHERE có thể được xử lý trước khi thực hiện JOIN. .Tuy nhiên, tôi đoán ngay cả khi bạn không thay đổi truy vấn ban đầu, trình tối ưu hóa sẽ có thể chuyển đổi thứ tự của chúng, nếu nó cho rằng hoạt động nối sẽ quá đắt với việc tìm nạp toàn bộ hàng, vì vậy nó sẽ áp dụng WHERE trước. Chỉ cần đoán của tôi.

Q2. biết rằng bảng 3 không thực sự cần thiết trong Bảng sao kê 2

Siêu dữ liệu sẽ diễn giải truy vấn thứ hai của bạn theo cách sao cho bảng dẫn xuất là cần thiết, vì vậy nó sẽ tiếp tục xử lý hoạt động của bảng 3 liên quan.

Answer 4

Tùy thuộc vào tính sẵn có của thống kê và chỉ mục cho các bảng được đề cập, cơ chế ghi đè truy vấn trong trình tối ưu hóa có thể hoặc không chọn quét Table2 cho các bản ghi trong đó val < 100 trước khi quét Table1.

Trong các tình huống nhất định, dựa trên dữ liệu nhân khẩu học, tham gia, lập chỉ mục và thống kê bạn có thể thấy rằng trình tối ưu hóa không loại bỏ các bản ghi trong kế hoạch truy vấn khi bạn cảm thấy cần. Ngay cả khi bạn có một bảng có nguồn gốc như bảng trong ví dụ của bạn. Bạn có thể ép trình tối ưu hóa xử lý một bảng có nguồn gốc bằng cách đặt một GROUP BY trong bảng có nguồn gốc của bạn. Trình tối ưu hóa sau đó được yêu cầu giải quyết tổng hợp GROUP BY trước khi nó có thể xem xét giải quyết sự kết hợp giữa hai bảng trong ví dụ của bạn.

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 

Điều này không có nghĩa là cách tiếp cận chuẩn của bạn nên chạy với điều này thông qua mã của bạn. Đây thường là một trong những khu nghỉ mát cuối cùng của tôi khi tôi có một kế hoạch truy vấn mà chỉ đơn giản là không loại bỏ hồ sơ không liên quan trước đó đủ trong kế hoạch và kết quả trong quá nhiều dữ liệu được quét và thực hiện xung quanh thông qua các tập tin SPOOL khác nhau. Đây chỉ đơn giản là một kỹ thuật bạn có thể đặt trong bộ công cụ của mình khi bạn gặp phải tình huống như vậy.

Cơ chế ghi lại truy vấn liên tục được cập nhật từ bản phát hành này sang bản phát hành tiếp theo và chi tiết về cách hoạt động có thể tìm thấy trong SQL Transaction Processing Manual cho Teradata 13.0.