Để đơn giản, giả sử tất cả các lĩnh vực có liên quan là NOT NULL.

Bạn có thể làm:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

Hoặc cái gì đó khác:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

Làm hai điều này trên cùng một cách trong MySQL?

INNER JOIN là cú pháp ANSI mà bạn nên sử dụng.

Nó thường được coi là dễ đọc hơn, đặc biệt là khi bạn tham gia nhiều bảng.

Nó cũng có thể dễ dàng thay thế bằng một OUTER JOIN bất cứ khi nào có nhu cầu.

Các WHERE cú pháp được mô hình quan hệ nhiều hướng.

Kết quả của hai bảng JOIN ed là một sản phẩm cartesian của các bảng mà bộ lọc được áp dụng, chỉ chọn những hàng có khớp cột.

Dễ dàng nhận thấy điều này với WHERECú pháp cú pháp.

Ví dụ của bạn, trong MySQL (và trong SQL nói chung) hai truy vấn này là từ đồng nghĩa.

Cũng lưu ý rằng MySQL cũng có một STRAIGHT_JOIN điều khoản.

Sử dụng mệnh đề này, bạn có thể kiểm soát JOIN thứ tự: bảng nào được quét ở vòng ngoài và bảng nào ở vòng trong.

Bạn không thể kiểm soát điều này trong MySQL bằng WHEREcú pháp.

Những người khác đã chỉ ra rằng INNER JOINgiúp con người dễ đọc, và đó là ưu tiên hàng đầu, tôi đồng ý.
Hãy để tôi cố gắng giải thích tại sao cú pháp tham gia dễ đọc hơn.

Một SELECTtruy vấn cơ bản là:

SELECT stuff
FROM tables
WHERE conditions

Điều SELECTkhoản cho chúng ta biết những gì chúng ta sẽ nhận lại; cácFROM khoản cho chúng ta biết nơi chúng tôi đang nhận được nó từ đâu, và các WHEREkhoản cho chúng ta biết mà những người chúng tôi đang nhận được.

JOIN là một tuyên bố về các bảng, làm thế nào chúng được liên kết với nhau (về mặt khái niệm, thực sự, vào một bảng duy nhất).

Bất kỳ yếu tố truy vấn nào kiểm soát các bảng - nơi chúng tôi nhận được nội dung - về mặt ngữ nghĩa thuộc về FROMmệnh đề (và tất nhiên, đó là nơi JOINcác yếu tố đi). Việc đưa các phần tử tham gia vào WHEREmệnh đề sẽ kết hợp giữa cái nào và từ đâu , đó là lý do tại sao JOINcú pháp được ưa thích.

Áp dụng các câu điều kiện trong ON / WHERE

Ở đây tôi đã giải thích về các bước xử lý truy vấn logic.

Tham khảo: Bên trong Microsoft® SQL Server ™ 2005
Nhà xuất bản truy vấn T-SQL : Microsoft Press
Pub Ngày: 07 tháng 3 năm 2006
In ISBN-10: 0-7356-2313-9
In ISBN-13: 980-0-7356-2313-2
Trang: 640

Bên trong Microsoft® SQL Server ™ 2005 Truy vấn T-SQL

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

Khía cạnh đáng chú ý đầu tiên của SQL khác với các ngôn ngữ lập trình khác là thứ tự xử lý mã. Trong hầu hết các ngôn ngữ lập trình, mã được xử lý theo thứ tự được viết. Trong SQL, mệnh đề đầu tiên được xử lý là mệnh đề TỪ, trong khi mệnh đề SELECT, xuất hiện đầu tiên, được xử lý gần như cuối cùng.

Mỗi bước tạo một bảng ảo được sử dụng làm đầu vào cho bước sau. Các bảng ảo này không có sẵn cho người gọi (ứng dụng khách hoặc truy vấn bên ngoài). Chỉ bảng được tạo bởi bước cuối cùng được trả về cho người gọi. Nếu một mệnh đề nhất định không được chỉ định trong truy vấn, bước tương ứng chỉ đơn giản là bỏ qua.

Mô tả ngắn gọn về các giai đoạn xử lý truy vấn logic

Đừng quá lo lắng nếu việc mô tả các bước dường như không có ý nghĩa gì cho đến bây giờ. Chúng được cung cấp như một tài liệu tham khảo. Các phần xuất hiện sau ví dụ kịch bản sẽ bao gồm các bước chi tiết hơn nhiều.

1. TỪ: Một sản phẩm của Cartesian (nối chéo) được thực hiện giữa hai bảng đầu tiên trong mệnh đề TỪ và kết quả là bảng ảo VT1 được tạo.

2. ON: Bộ lọc ON được áp dụng cho VT1. Chỉ các hàng có <join_condition>TRUE được chèn vào VT2.

3. OUTER (tham gia): Nếu một OUTER THAM GIA được chỉ định (trái ngược với CROSS THAM GIA hoặc INNER THAM GIA), các hàng từ bảng được bảo tồn hoặc các bảng không tìm thấy kết quả khớp được thêm vào các hàng từ VT2 dưới dạng các hàng ngoài, tạo ra VT3. Nếu có nhiều hơn hai bảng xuất hiện trong mệnh đề TỪ, các bước từ 1 đến 3 được áp dụng lặp đi lặp lại giữa kết quả của lần nối cuối cùng và bảng tiếp theo trong mệnh đề TỪ cho đến khi tất cả các bảng được xử lý.

4. WHERE: Bộ lọc WHERE được áp dụng cho VT3. Chỉ các hàng có <where_condition>TRUE được chèn vào VT4.

5. NHÓM THEO: Các hàng từ VT4 được sắp xếp theo nhóm dựa trên danh sách cột được chỉ định trong mệnh đề GROUP BY. VT5 được tạo ra.

6. CUBE | ROLLUP: Siêu nhóm (nhóm các nhóm) được thêm vào các hàng từ VT5, tạo VT6.

7. HAVING: Bộ lọc HAVING được áp dụng cho VT6. Chỉ các nhóm có <having_condition>TRUE được chèn vào VT7.

8. CHỌN: Danh sách CHỌN được xử lý, tạo VT8.

9. DISTINCT: Các hàng trùng lặp được xóa khỏi VT8. VT9 được tạo ra.

10. ORDER BY: Các hàng từ VT9 được sắp xếp theo danh sách cột được chỉ định trong mệnh đề ORDER BY. Một con trỏ được tạo ra (VC10).

11. TOP: Số lượng hoặc tỷ lệ phần trăm của các hàng được chỉ định từ đầu VC10. Bảng VT11 được tạo và trả lại cho người gọi.

(Áp dụng các câu lệnh có điều kiện trong ON / WHERE sẽ không tạo ra nhiều khác biệt trong một số trường hợp. Điều này phụ thuộc vào số lượng bảng bạn đã tham gia và số lượng hàng có sẵn trong mỗi bảng tham gia)

Cú pháp tham gia ngầm định ANSI cũ hơn, ít rõ ràng hơn và không được đề xuất.

Ngoài ra, đại số quan hệ cho phép khả năng hoán đổi của các vị từ trong WHEREmệnh đề và INNER JOIN, do đó, ngay cả INNER JOINcác truy vấn vớiWHERE mệnh đề cũng có thể có các vị từ được sắp xếp lại bởi trình tối ưu hóa.

Tôi khuyên bạn nên viết các truy vấn theo cách dễ đọc nhất có thể.

Đôi khi điều này bao gồm làm cho INNER JOINtương đối "không đầy đủ" và đưa một số tiêu chí vàoWHERE cách đơn giản để làm cho danh sách các tiêu chí lọc dễ dàng duy trì hơn.

Ví dụ: thay vì:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Viết:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Nhưng nó phụ thuộc, tất nhiên.

Các phép nối ngầm định (đó là những gì truy vấn đầu tiên của bạn được biết đến) trở nên khó hiểu hơn, khó đọc và khó duy trì hơn một khi bạn cần bắt đầu thêm nhiều bảng vào truy vấn của mình. Hãy tưởng tượng thực hiện cùng một truy vấn và loại tham gia trên bốn hoặc năm bảng khác nhau ... đó là một cơn ác mộng.

Sử dụng một phép nối rõ ràng (ví dụ thứ hai của bạn) sẽ dễ đọc hơn và dễ bảo trì hơn.

Tôi cũng sẽ chỉ ra rằng việc sử dụng cú pháp cũ có nhiều lỗi hơn. Nếu bạn sử dụng các phép nối bên trong mà không có mệnh đề ON, bạn sẽ gặp lỗi cú pháp. Nếu bạn sử dụng cú pháp cũ hơn và quên một trong các điều kiện nối trong mệnh đề where, bạn sẽ nhận được một phép nối chéo. Các nhà phát triển thường khắc phục điều này bằng cách thêm từ khóa riêng biệt (thay vì sửa lỗi liên kết vì họ vẫn không nhận ra chính liên kết bị hỏng) có thể khắc phục sự cố, nhưng sẽ làm chậm đáng kể truy vấn.

Ngoài ra để bảo trì nếu bạn có một tham gia chéo trong cú pháp cũ, làm thế nào để người bảo trì biết nếu bạn muốn có một (có những tình huống cần tham gia chéo) hoặc nếu đó là một tai nạn cần được khắc phục?

Hãy để tôi chỉ cho bạn câu hỏi này để xem tại sao cú pháp ngầm là xấu nếu bạn sử dụng các phép nối trái. Sybase * = to Ansi Standard với 2 bảng bên ngoài khác nhau cho cùng một bảng bên trong

Thêm vào đó (câu chuyện cá nhân ở đây), tiêu chuẩn sử dụng các phép nối rõ ràng đã hơn 20 năm, điều đó có nghĩa là cú pháp nối ngầm đã bị lỗi thời trong 20 năm đó. Bạn có thể viết mã ứng dụng bằng cú pháp đã lỗi thời trong 20 năm không? Tại sao bạn muốn viết mã cơ sở dữ liệu?

Chúng có một ý nghĩa khác nhau có thể đọc được của con người.

Tuy nhiên, tùy thuộc vào trình tối ưu hóa truy vấn, chúng có thể có cùng ý nghĩa với máy.

Bạn nên luôn luôn mã để có thể đọc được.

Điều đó có nghĩa là, nếu đây là mối quan hệ tích hợp, hãy sử dụng phép nối rõ ràng. nếu bạn khớp với dữ liệu liên quan yếu, hãy sử dụng mệnh đề where.

Tiêu chuẩn SQL: 2003 đã thay đổi một số quy tắc ưu tiên để câu lệnh THAM GIA được ưu tiên so với phép nối "dấu phẩy". Điều này thực sự có thể thay đổi kết quả truy vấn của bạn tùy thuộc vào cách thiết lập. Điều này gây ra một số vấn đề cho một số người khi MySQL 5.0.12 chuyển sang tuân thủ tiêu chuẩn.

Vì vậy, trong ví dụ của bạn, các truy vấn của bạn sẽ hoạt động như nhau. Nhưng nếu bạn đã thêm bảng thứ ba: CHỌN ... TỪ bảng1, bảng2 THAM GIA bảng3 TRÊN ... Ở ĐÂU ...

Trước MySQL 5.0.12, bảng1 và bảng2 sẽ được nối trước, sau đó đến bảng 3. Bây giờ (5.0.12 trở đi), bảng2 và bảng3 được nối trước, sau đó đến bảng1. Nó không luôn luôn thay đổi kết quả, nhưng nó có thể và bạn thậm chí có thể không nhận ra nó.

Tôi không bao giờ sử dụng cú pháp "dấu phẩy" nữa, chọn ví dụ thứ hai của bạn. Dù sao nó cũng dễ đọc hơn rất nhiều, các điều kiện THAM GIA với các THAM GIA, không được tách thành một phần truy vấn riêng.

Tôi biết bạn đang nói về MySQL, nhưng dù sao: Trong Oracle 9, các phép nối rõ ràng và các phép nối ngầm sẽ tạo ra các kế hoạch thực hiện khác nhau. AFAIK đã được giải quyết trong Oracle 10+: không còn sự khác biệt như vậy nữa.

Cú pháp tham gia ANSI chắc chắn là dễ mang theo hơn.

Tôi đang tiến hành nâng cấp Microsoft SQL Server và tôi cũng sẽ đề cập rằng cú pháp = * và * = cho các phép nối ngoài trong SQL Server không được hỗ trợ (không có chế độ tương thích) cho máy chủ sql 2005 và sau đó.

Nếu bạn thường lập trình các thủ tục lưu trữ động, bạn sẽ yêu ví dụ thứ hai của mình (sử dụng ở đâu). Nếu bạn có nhiều thông số đầu vào khác nhau và nhiều mớ hỗn độn, thì đó là cách duy nhất. Nếu không, cả hai sẽ chạy cùng một kế hoạch truy vấn nên chắc chắn không có sự khác biệt rõ ràng trong các truy vấn cổ điển.