2010-06-29 42 views
7

Tôi đã xem qua cách viết các truy vấn theo những cách differnt như hình dưới đây Type-Imà truy vấn là tốt hơn và hiệu quả - mysql

SELECT JS.JobseekerID 
     , JS.FirstName 
     , JS.LastName 
     , JS.Currency 
     , JS.AccountRegDate 
     , JS.LastUpdated 
     , JS.NoticePeriod 
     , JS.Availability 
     , C.CountryName 
     , S.SalaryAmount 
     , DD.DisciplineName 
     , DT.DegreeLevel 
    FROM Jobseekers JS 
INNER 
    JOIN Countries C 
     ON JS.CountryID = C.CountryID 
INNER 
    JOIN SalaryBracket S 
     ON JS.MinSalaryID = S.SalaryID 
INNER 
    JOIN DegreeDisciplines DD 
    ON JS.DegreeDisciplineID = DD.DisciplineID 
INNER 
    JOIN DegreeType DT 
    ON JS.DegreeTypeID = DT.DegreeTypeID 
WHERE 
    JS.ShowCV = 'Yes' 

Type-II

SELECT JS.JobseekerID 
     , JS.FirstName 
     , JS.LastName 
     , JS.Currency 
     , JS.AccountRegDate 
     , JS.LastUpdated 
     , JS.NoticePeriod 
     , JS.Availability 
     , C.CountryName 
     , S.SalaryAmount 
     , DD.DisciplineName 
     , DT.DegreeLevel 
    FROM Jobseekers JS, Countries C, SalaryBracket S, DegreeDisciplines DD 
     , DegreeType DT 
    WHERE 
      JS.CountryID = C.CountryID 
      AND JS.MinSalaryID = S.SalaryID 
      AND JS.DegreeDisciplineID = DD.DisciplineID 
      AND JS.DegreeTypeID = DT.DegreeTypeID 
      AND JS.ShowCV = 'Yes' 

Tôi sử dụng cơ sở dữ liệu Mysql

Cả hai hoạt động thực sự tốt, Nhưng tôi tự hỏi

  1. cách tốt nhất để sử dụng mọi lúc cho mọi tình huống?
  2. Hiệu suất khôn ngoan tốt hơn? (Hãy nói cơ sở dữ liệu dưới dạng hàng triệu bản ghi)
  3. Bất kỳ ưu điểm nào vượt trội hơn?
  4. Có công cụ nào để tôi có thể kiểm tra truy vấn nào tốt hơn không?

Cảm ơn trước

+0

chỉnh sửa: Scorpi0 đề cập đến nó khá tốt, hãy nhớ xem SO-link của mình – DrColossos

+0

nop, DBMS phát hiện tham gia bên trong, nó không thực hiện kết nối chéo –

+0

hmm, tôi nghĩ rằng tôi đọc nó ở đâu đó trong các diễn đàn MySQL, nhưng bạn có thể đúng về nó. Có lẽ tôi có thể tìm thấy các articlem nhờ chỉ ra mặc dù! – DrColossos

Trả lời

10

1- Đó là không có trí tuệ, sử dụng các loại I

2- Các loại II join còn được gọi là 'ngầm tham gia', trong khi loại I được gọi là 'rõ ràng tham gia'. Với DBMS hiện đại, bạn sẽ không gặp bất kỳ vấn đề về hiệu suất nào với truy vấn thông thường. Nhưng tôi nghĩ với một số truy vấn phức tạp đa tham gia, DBMS có thể có vấn đề với sự tham gia ngầm định. Sử dụng tham gia rõ ràng chỉ có thể cải thiện kế hoạch giải thích của bạn, vì vậy kết quả nhanh hơn!

3- Vì vậy, hiệu suất có thể là một vấn đề, nhưng quan trọng nhất có thể, khả năng đọc được cải thiện để bảo trì thêm. Tham gia rõ ràng giải thích chính xác những gì bạn muốn tham gia vào lĩnh vực nào, trong khi tham gia ngầm không hiển thị nếu bạn thực hiện một tham gia hoặc một bộ lọc. Mệnh đề Where là dành cho bộ lọc, không phải để tham gia!

Và một điểm lớn lớn để tham gia rõ ràng: tham gia bên ngoài thực sự gây phiền nhiễu với tham gia ngầm định. Thật khó để đọc khi bạn muốn nhiều tham gia với tham gia bên ngoài mà tham gia rõ ràng là THE giải pháp.

4 kế hoạch thực hiện là những gì bạn cần (See the doc)

Một số bản sao:

Explicit vs implicit SQL joins

SQL join: where clause vs. on clause

INNER JOIN ON vs WHERE clause

1

trong mã nhất tôi đã nhìn thấy, những querys được thực hiện như bạn Type-II - nhưng tôi nghĩ rằng Type-I là tốt hơn vì khả năng đọc (và logic hơn - một tham gia là một tham gia, vì vậy bạn nên viết nó như là một tham gia (althoug thứ hai chỉ là một phong cách viết cho tham gia bên trong)).

về hiệu suất, không nên có sự khác biệt (nếu có, tôi nghĩ Type-I sẽ nhanh hơn một chút).

1

Đề nghị của tôi.

Cập nhật tất cả các bảng của bạn với một số lượng bản ghi. Truy cập vào giao diện điều khiển MySQL và chạy SQL cả hai lệnh một. Bạn có thể thấy thời gian thực hiện trong bảng điều khiển.

1

Đối với hai truy vấn mà bạn đề cập (mỗi với chỉ tham gia bên trong) mọi truy vấn tối ưu hóa của cơ sở dữ liệu hiện đại r nên sản xuất chính xác cùng một kế hoạch truy vấn, và do đó hiệu suất tương tự.

Đối với MySQL, nếu bạn đặt tiền tố truy vấn với EXPLAIN, nó sẽ nhổ ra thông tin về kế hoạch truy vấn (thay vì chạy truy vấn). Nếu thông tin từ cả hai truy vấn giống nhau, thì kế hoạch truy vấn là như nhau và hiệu suất sẽ giống nhau. Từ MySQL Reference Manual:

GIẢI THÍCH trả về một hàng thông tin cho mỗi bảng được sử dụng trong câu lệnh SELECT. Các bảng được liệt kê trong kết quả theo thứ tự mà MySQL sẽ đọc chúng khi xử lý truy vấn . MySQL giải quyết tất cả các phép nối bằng cách sử dụng một phương thức nối vòng lặp lồng nhau. Điều này có nghĩa là rằng MySQL đọc một hàng từ bảng đầu tiên và sau đó tìm một hàng phù hợp trong bảng thứ hai, bảng thứ ba, và cứ tiếp tục như vậy. Khi tất cả các bảng được xử lý , MySQL sẽ xuất ra các cột được chọn và backtracks qua danh sách bảng cho đến khi tìm thấy bảng cho có nhiều hàng phù hợp hơn. Hàng tiếp theo được đọc từ bảng này và quá trình tiếp tục với bảng tiếp theo.

Khi từ khóa EXTENDED được sử dụng, GIẢI THÍCH tạo ra thêm thông tin có thể được xem bằng cách phát hành một tuyên bố HIỂN THỊ CẢNH BÁO sau GIẢI THÍCH tuyên bố. Thông tin này hiển thị cách trình tối ưu hóa đủ điều kiện tên bảng và cột trong câu lệnh SELECT , SELECT là gì sau khi áp dụng quy tắc tối ưu hóa và và có thể ghi chú khác về quy trình tối ưu hóa.

Cú pháp nào tốt hơn? Điều đó tùy thuộc vào bạn, nhưng một khi bạn di chuyển ra ngoài các kết nối bên trong với các phép nối ngoài, bạn sẽ cần phải sử dụng cú pháp mới hơn, vì không có tiêu chuẩn để mô tả các phép nối ngoài bằng cách sử dụng cú pháp nối ngầm cũ hơn.

Các vấn đề liên quan