Tăng tốc độ tham gia bên trong giữa một bảng lớn và một bảng nhỏ

Question

Đây có thể là một câu hỏi ngớ ngẩn, nhưng nó có thể làm sáng tỏ cách thức hoạt động của nội bộ.

Giả sử tôi có một bảng lớn L và một bảng nhỏ S (100 nghìn hàng so với 100 hàng).

Nên có bất kỳ sự khác biệt về tốc độ giữa hai tùy chọn sau đây ?:

OPTION 1:     OPTION 2: 
---------     --------- 
SELECT *     SELECT * 
FROM L INNER JOIN S  FROM S INNER JOIN L 
ON L.id = S.id;   ON L.id = S.id; 

Chú ý rằng sự khác biệt duy nhất là thứ tự mà các bảng với nhau.

Tôi nhận thấy hiệu suất có thể khác nhau giữa các ngôn ngữ SQL khác nhau. Nếu vậy, MySQL sẽ so sánh với Access như thế nào?

Answer 1

Không, thứ tự không quan trọng.

Hầu như tất cả RDBMS (như MS Access, MySQL, SQL Server, ORACLE, v.v ...) đều sử dụng trình tối ưu hóa dựa trên thống kê cột. Trong hầu hết các trường hợp, người tối ưu hóa sẽ chọn một gói đúng. Trong ví dụ bạn đưa ra, thứ tự sẽ không quan trọng (các thống kê được cung cấp được cập nhật).

Để quyết định chiến lược truy vấn nào sẽ sử dụng, Trình tối ưu hóa công cụ phản lực sử dụng số liệu thống kê . Các yếu tố sau là một số trong những yếu tố mà những thống kê dựa trên:

• Số lượng các bản ghi trong một bảng
• Số lượng các trang dữ liệu trong một bảng
• Vị trí của bảng
• chỉ số dù có mặt
• Làm thế nào duy nhất chỉ là

Lưu ý: Bạn không thể xem lược đồ tối ưu hóa cơ sở dữ liệu máy bay phản lực và bạn không thể chỉ định cách tối ưu hóa truy vấn . Tuy nhiên, bạn có thể sử dụng Cơ sở dữ liệu Documenter để xác định liệu các chỉ mục có hiện diện hay không và cách chỉ mục của một chỉ mục là .

Dựa trên các thống kê này, Trình tối ưu hóa sau đó chọn chiến lược truy vấn nội bộ tốt nhất để xử lý với truy vấn cụ thể.

Số liệu thống kê được cập nhật bất cứ khi nào một truy vấn được biên soạn. Truy vấn bị gắn cờ để biên dịch khi bạn lưu bất kỳ thay đổi nào đối với truy vấn (hoặc bảng cơ bản) và khi cơ sở dữ liệu được nén chặt. Nếu truy vấn là được gắn cờ để biên soạn, biên dịch và cập nhật thống kê xảy ra lần sau khi truy vấn được chạy. Biên dịch thường lấy từ một trong số từ giây đến bốn giây.

Nếu bạn thêm một số lượng đáng kể hồ sơ để cơ sở dữ liệu của bạn, bạn phải mở và sau đó lưu các truy vấn của bạn để biên dịch lại các truy vấn. Ví dụ: nếu bạn thiết kế và sau đó kiểm tra truy vấn theo bằng cách sử dụng một tập dữ liệu mẫu nhỏ, bạn phải biên dịch lại truy vấn sau hồ sơ bổ sung được thêm vào cơ sở dữ liệu . Khi bạn làm điều này, bạn muốn để đảm bảo rằng truy vấn tối ưu hiệu suất đạt được khi ứng dụng của bạn đang được sử dụng.

Ref.

Có thể quan tâm: ACC: How to Optimize Queries in Microsoft Access 2.0, Microsoft Access 95, and Microsoft Access 97

Tony Toews của Microsoft Access Performance FAQ rất đáng đọc.

Answer 2

Tôi biết Oracle không có trong danh sách của bạn, nhưng tôi nghĩ rằng cơ sở dữ liệu hiện đại nhất sẽ hành xử theo cách đó.

Bạn có thể thấy trong kế hoạch thực hiện sau, rằng không có sự khác biệt giữa hai câu lệnh.

Đó là quyền truy cập đầy đủ vào từng bảng trong số hai bảng (không có chỉ mục trong trường hợp của tôi), và sau đó là HASH JOIN. Vì bạn muốn mọi thứ từ cả hai bảng, cả hai bảng cần được đọc và tham gia, chuỗi không có tác động.

--------------------------------------------------------------------------- 
| Id | Operation   | Name | Rows | Bytes | Cost (%CPU)| Time  | 
--------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |  | 100 | 700 | 42 (12)| 00:00:01 | 
|* 1 | HASH JOIN   |  | 100 | 700 | 42 (12)| 00:00:01 | 
| 2 | TABLE ACCESS FULL| S | 100 | 300 |  2 (0)| 00:00:01 | 
| 3 | TABLE ACCESS FULL| L | 100K| 390K| 38 (8)| 00:00:01 | 
---------------------------------------------------------------------------