SQL rõ ràng và tham gia SQL tham gia

Có sự khác biệt hiệu quả trong một kết nối bên trong rõ ràng và ngầm? Ví dụ:

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

so với

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

Hiệu suất khôn ngoan, chúng hoàn toàn giống nhau (ít nhất là trong SQL Server).

PS: Xin lưu ý rằng IMPLICIT OUTER JOINcú pháp không được dùng kể từ SQL Server 2005. ( IMPLICIT INNER JOINCú pháp như được sử dụng trong câu hỏi vẫn được hỗ trợ)

Sự phản đối của "Kiểu cũ" THAM GIA Cú pháp: Chỉ một phần

Cá nhân tôi thích cú pháp nối vì nó làm rõ hơn rằng các bảng được nối và cách chúng được nối. Hãy thử so sánh các truy vấn SQL lớn hơn nơi bạn chọn từ 8 bảng khác nhau và bạn có rất nhiều bộ lọc ở đâu. Bằng cách sử dụng cú pháp nối, bạn tách ra các phần trong đó các bảng được nối, đến phần bạn đang lọc các hàng.

Trên MySQL 5.1.51, cả hai truy vấn đều có kế hoạch thực hiện giống hệt nhau:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1có 166208 hàng; table2có khoảng 1000 hàng.

Đây là một trường hợp rất đơn giản; điều đó không có nghĩa là chứng minh rằng trình tối ưu hóa truy vấn sẽ không bị lẫn lộn và tạo ra các kế hoạch khác nhau trong trường hợp phức tạp hơn.

Cú pháp thứ hai có khả năng không mong muốn của phép nối chéo: bạn có thể thêm các bảng vào phần TỪ mà không cần mệnh đề WHERE tương ứng. Điều này được coi là có hại.

Câu trả lời đầu tiên bạn đưa ra sử dụng cú pháp tham gia ANSI, câu trả lời khác là hợp lệ và sẽ hoạt động trong bất kỳ cơ sở dữ liệu quan hệ nào.

Tôi đồng ý với grom rằng bạn nên sử dụng cú pháp tham gia ANSI. Như họ đã nói, lý do chính là cho sự rõ ràng. Thay vì có một mệnh đề where có nhiều biến vị ngữ, một số trong đó tham gia các bảng và một số khác giới hạn các hàng được trả về bằng cú pháp nối ANSI, bạn đang làm cho nó rõ ràng những điều kiện nào đang được sử dụng để tham gia các bảng của bạn và đang được sử dụng để hạn chế các kết quả.

Hiệu suất khôn ngoan, chúng hoàn toàn giống nhau (ít nhất là trong SQL Server) nhưng lưu ý rằng chúng không dùng cú pháp nối này và nó không được hỗ trợ bởi sql server2005.

Tôi nghĩ rằng bạn đang nghĩ về các toán tử * = và = * không dùng nữa so với "tham gia ngoài".

Tôi vừa mới thử nghiệm hai định dạng đã cho và chúng hoạt động chính xác trên cơ sở dữ liệu SQL Server 2008. Trong trường hợp của tôi, họ đã mang lại kế hoạch thực hiện giống hệt nhau, nhưng tôi không thể tự tin nói rằng điều này sẽ luôn đúng.

@lomaxx: Chỉ cần làm rõ, tôi khá chắc chắn rằng cả hai cú pháp trên đều được SQL Serv 2005 hỗ trợ. Tuy nhiên cú pháp bên dưới KHÔNG được hỗ trợ

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

Cụ thể, nối ngoài (* =) không được hỗ trợ.

Trên một số cơ sở dữ liệu (đặc biệt là Oracle), thứ tự của các phép nối có thể tạo ra sự khác biệt lớn đối với hiệu năng truy vấn (nếu có nhiều hơn hai bảng). Trên một ứng dụng, chúng tôi có hai đơn hàng chênh lệch cường độ trong một số trường hợp. Sử dụng cú pháp nối bên trong cho phép bạn kiểm soát điều này - nếu bạn sử dụng cú pháp gợi ý đúng.

Bạn đã không chỉ định cơ sở dữ liệu nào bạn đang sử dụng, nhưng xác suất đề xuất SQL Server hoặc MySQL, nơi nó không có sự khác biệt thực sự.

Như Leigh Caldwell đã tuyên bố, trình tối ưu hóa truy vấn có thể tạo ra các gói truy vấn khác nhau dựa trên chức năng trông giống như câu lệnh SQL. Để đọc thêm về điều này, hãy xem hai bài đăng trên blog sau: -

Một bài đăng từ Nhóm Trình tối ưu hóa Oracle

Một bài đăng khác từ blog "Dữ liệu có cấu trúc"

Tôi hy vọng bạn tìm thấy điều này thú vị.

Hiệu suất khôn ngoan, nó không nên làm cho bất kỳ sự khác biệt. Cú pháp nối rõ ràng có vẻ sạch hơn đối với tôi vì nó xác định rõ mối quan hệ giữa các bảng trong mệnh đề from và không làm lộn xộn mệnh đề where.

Về cơ bản, sự khác biệt giữa hai là một cái được viết theo cách cũ, trong khi cái kia được viết theo cách hiện đại. Cá nhân, tôi thích tập lệnh hiện đại sử dụng các định nghĩa bên trong, bên trái, bên ngoài, bên phải bởi vì chúng dễ giải thích hơn và làm cho mã dễ đọc hơn.

Tuy nhiên, khi xử lý các phép nối bên trong, không có sự khác biệt thực sự về khả năng đọc, nó có thể trở nên phức tạp khi xử lý các phép nối trái và phải như trong phương thức cũ hơn bạn sẽ có được một cái gì đó như thế này:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

Trên đây là cách cũ về cách viết bên trái được viết trái ngược với những điều sau:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

Như bạn có thể thấy, cách hiện đại của cách viết kịch bản làm cho truy vấn dễ đọc hơn. (Nhân tiện cũng vậy đối với các phép nối phải và phức tạp hơn một chút đối với các phép nối ngoài).

Quay trở lại tấm nồi hơi, nó không tạo ra sự khác biệt cho trình biên dịch SQL về cách truy vấn được viết khi nó xử lý chúng theo cùng một cách. Tôi đã thấy một sự kết hợp của cả hai trong cơ sở dữ liệu của Oracle, nơi có nhiều người viết vào đó, cả người già và người trẻ. Một lần nữa, nó tập trung vào mức độ dễ đọc của kịch bản và nhóm bạn đang phát triển.

Theo kinh nghiệm của tôi, việc sử dụng cú pháp liên kết ngang với mệnh đề thường tạo ra một kế hoạch thực thi bị tổn thương não, đặc biệt nếu bạn đang sử dụng một sản phẩm Microsoft SQL. Chẳng hạn, cách mà SQL Server cố gắng ước tính số lượng hàng của bảng, thật khủng khiếp. Sử dụng cú pháp nối bên trong cung cấp cho bạn một số kiểm soát về cách thực hiện truy vấn. Vì vậy, từ quan điểm thực tế, với bản chất tự nhiên của công nghệ cơ sở dữ liệu hiện tại, bạn phải đi với sự tham gia bên trong.