Tôi đã làm việc cho các công ty khác nhau và tôi nhận thấy rằng một số người trong số họ thích có quan điểm sẽ tham gia một bảng với tất cả "người thân" của nó. Nhưng sau đó trên ứng dụng một số lần, chúng ta chỉ cần sử dụng 1 cột.

Vì vậy, sẽ nhanh hơn nếu chỉ thực hiện các lựa chọn đơn giản và sau đó "tham gia" chúng vào mã hệ thống?

Hệ thống có thể là php, java, asp, bất kỳ ngôn ngữ nào kết nối với cơ sở dữ liệu.

Vì vậy, câu hỏi là, cái gì nhanh hơn từ phía Máy chủ (php, java, asp, ruby, python ...) đến cơ sở dữ liệu chạy một truy vấn có được mọi thứ chúng ta cần hoặc đi từ phía máy chủ đến cơ sở dữ liệu và chạy một truy vấn chỉ nhận được các cột từ một bảng tại thời điểm đó?

Điều gì sẽ giải quyết câu hỏi của bạn là chủ đề THAM GIA KHAI THÁC.

Theo trang 209 của cuốn sách

Bạn có thể phân tách một phép nối bằng cách chạy nhiều truy vấn một bảng thay vì nối nhiều lần, sau đó thực hiện phép nối trong ứng dụng. Ví dụ: thay vì truy vấn này:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Bạn có thể chạy các truy vấn sau:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

Tại sao trên trái đất bạn sẽ làm điều này? Thoạt nhìn có vẻ lãng phí, vì bạn đã tăng số lượng truy vấn mà không nhận được bất cứ điều gì. Tuy nhiên, việc tái cấu trúc như vậy thực sự có thể mang lại lợi thế đáng kể về hiệu suất:

• Bộ nhớ đệm có thể hiệu quả hơn. Nhiều ứng dụng lưu trữ các "đối tượng" ánh xạ trực tiếp vào các bảng. Trong ví dụ này, nếu đối tượng có thẻ mysqlđã được lưu vào bộ đệm, ứng dụng sẽ bỏ qua truy vấn đầu tiên. Nếu bạn tìm thấy các bài đăng có ID là 123, 567 hoặc 908 trong bộ đệm, bạn có thể xóa chúng khỏi IN()danh sách. Bộ đệm truy vấn cũng có thể được hưởng lợi từ chiến lược này. Nếu chỉ một trong các bảng thay đổi thường xuyên, việc phân tách một phép nối có thể làm giảm số lượng mất hiệu lực của bộ đệm.
• Thực hiện các truy vấn riêng lẻ đôi khi có thể làm giảm sự tranh chấp khóa
• Việc tham gia trong ứng dụng giúp dễ dàng mở rộng cơ sở dữ liệu bằng cách đặt các bảng trên các máy chủ khác nhau.
• Các truy vấn có thể được hiệu quả hơn. Trong ví dụ này, sử dụng IN()danh sách thay vì tham gia cho phép MySQL sắp xếp ID hàng và truy xuất hàng tối ưu hơn mức có thể có với liên kết.
• Bạn có thể giảm truy cập hàng dự phòng. Tham gia vào ứng dụng có nghĩa là chỉ truy xuất mỗi hàng một lần. Trong khi đó, việc tham gia truy vấn về cơ bản là sự không chuẩn hóa có thể truy cập nhiều lần vào cùng một dữ liệu. Vì lý do tương tự, việc tái cấu trúc như vậy cũng có thể làm giảm tổng lưu lượng mạng và sử dụng bộ nhớ.
• Ở một mức độ nào đó, bạn có thể xem kỹ thuật này khi thực hiện thủ công hàm băm thay vì thuật toán vòng lặp lồng nhau mà MySQL sử dụng để thực hiện phép nối. Một phép nối băm có thể hiệu quả hơn.

Do đó, các thao tác tham gia trong ứng dụng có thể hiệu quả hơn khi bạn lưu trữ và sử dụng lại nhiều dữ liệu từ các truy vấn trước đó, bạn phân phối dữ liệu trên nhiều máy chủ, bạn thay thế các liên kết bằng IN()danh sách hoặc liên kết tham chiếu đến cùng một bảng nhiều lần.

QUAN SÁT

Tôi thích dấu đầu dòng đầu tiên vì InnoDB hơi nặng tay khi kiểm tra chéo bộ đệm truy vấn.

• Sep 05, 2012: Là chi phí chung của việc vô hiệu hóa bộ đệm truy vấn thường xuyên có bao giờ đáng không?
• Jun 07, 2014: Tại sao query_cache_type bị tắt theo mặc định bắt đầu từ MySQL 5.6?

Đối với gạch đầu dòng cuối cùng, tôi đã viết một bài đăng lại vào ngày 11 tháng 3 năm 2013 ( Có sự khác biệt thực thi giữa điều kiện THAM GIA và điều kiện WHERE không? ) Mô tả thuật toán vòng lặp lồng nhau. Sau khi đọc nó, bạn sẽ thấy sự phân rã tham gia tốt như thế nào.

Đối với tất cả các điểm khác từ cuốn sách , các nhà phát triển thực sự tìm kiếm hiệu suất là điểm mấu chốt. Một số người dựa vào các phương tiện bên ngoài (bên ngoài ứng dụng) để cải tiến hiệu suất như sử dụng đĩa nhanh, nhận thêm CPU / lõi, điều chỉnh công cụ lưu trữ và điều chỉnh tệp cấu hình. Những người khác sẽ khóa xuống và viết mã tốt hơn. Một số người có thể sử dụng mã hóa tất cả các thông tin nghiệp vụ trong Thủ tục lưu trữ nhưng vẫn không áp dụng phân tách tham gia (Xem các đối số chống lại hoặc để đưa logic ứng dụng vào lớp cơ sở dữ liệu cùng với các bài đăng khác). Tất cả tùy thuộc vào văn hóa và khả năng chịu đựng của mỗi cửa hàng phát triển.

Một số có thể hài lòng với hiệu suất và không chạm vào mã nữa. Khác đơn giản là không nhận ra có những lợi ích tuyệt vời mà người ta có thể gặt hái nếu họ thử tham gia sáng tác.

Đối với những nhà phát triển sẵn sàng ...

HÃY THỬ MỘT LẦN !!!

Trong Postgres (và có thể là bất kỳ RDBMS nào ở mức độ tương tự, MySQL ở mức độ thấp hơn), ít truy vấn hơn hầu như luôn luôn nhanh hơn nhiều .

Chi phí phân tích cú pháp và lập kế hoạch nhiều truy vấn đã nhiều hơn bất kỳ lợi ích nào có thể có trong hầu hết các trường hợp.

Không nói về công việc bổ sung sẽ được thực hiện trong máy khách, kết hợp các kết quả, thường chậm hơn nhiều . Một RDBMS chuyên về loại nhiệm vụ và hoạt động đó dựa trên các loại dữ liệu gốc. Không truyền tới textvà quay lại các kết quả trung gian hoặc chuyển đổi sang các kiểu máy khách gốc, điều này thậm chí có thể dẫn đến kết quả ít chính xác hơn (hoặc không chính xác!). Hãy nghĩ về số dấu phẩy động ...

Bạn cũng chuyển nhiều dữ liệu hơn giữa máy chủ DB và máy khách. Điều này có thể không đáng kể cho một bàn tay đầy giá trị, hoặc tạo ra một sự khác biệt lớn.

Nếu nhiều truy vấn có nghĩa là nhiều chuyến đi khứ hồi đến máy chủ cơ sở dữ liệu, bạn cũng thu thập nhiều lần độ trễ của mạng và chi phí giao dịch, thậm chí có thể cả chi phí kết nối. Lớn, mất lớn.

Tùy thuộc vào thiết lập của bạn, độ trễ mạng một mình có thể mất nhiều thời gian hơn tất cả các phần còn lại theo đơn đặt hàng cường độ.

Câu hỏi liên quan về SO:

• Cái nào tốt hơn? Thực hiện tính toán trong sql hoặc trong ứng dụng của bạn

Có thể có một bước ngoặt cho rất lớn , truy vấn chạy dài vì các giao dịch thu thập ổ khóa trên DB hàng trên đường đi. Các truy vấn rất lớn có thể giữ nhiều khóa trong một khoảng thời gian dài có thể gây ra ma sát với các truy vấn đồng thời .