Bao nhiêu truy vấn SQL là quá nhiều truy vấn SQL?

Question

Tôi đã nghiên cứu một CMS để sử dụng và chạy vào một đánh giá trên vBulletin 4.0; sử dụng khoảng 200 truy vấn trên một lần tải trang.

Tôi đã lo lắng rồi.

Tiếp tục nghiên cứu đưa tôi đến các trang web khác để xem có bao nhiêu truy vấn họ đang sử dụng và tôi phát hiện ra rằng một số phần mềm diễn đàn như Invision Power Board và PHPBB đang sử dụng các truy vấn càng thấp càng 6 hoặc 8.

Hiện nay, tôi trang web sử dụng khoảng 25 đến 40 truy vấn.

Tôi có nên lo lắng không?

Answer 1

Đừng lo lắng về số lượng truy vấn.

Hãy lo lắng về:

1. trang tải quá chậm
2. SQL quá phức tạp để duy trì.

Làm rõ:

SQL là quá phức tạp có thể đến từ một trong hai quá nhiều truy vấn hoặc một vài câu hỏi mà rất phức tạp (nhiều gia nhập và truy vấn phụ, vv).

Answer 2

Nếu bạn nhắm mục tiêu gì đó, hãy nhắm mục tiêu 3 lần đọc và viết 1 lần cho mỗi lần truy cập HTTP.

Trong khi đây là những con số tùy ý (bằng cách nào đó, họ đang thực sự lấy từ Advanced PHP Programming), họ nhấn mạnh ý tưởng:

• số của SQL roundtrips nên thấp, dưới 10 tuổi chắc chắn, mỗi HTTP gọi
• có sự khác biệt giữa số lần đọc và ghi và tỷ lệ phải ưu tiên số lần đọc. viết tạo tranh

Cũng nên nhớ rằng không phải tất cả đều bình đẳng lần đọc: 3 lần đọc nên được tối ưu hóa cao đọc, không quét bảng đầy đủ với 4-5 outer joins ...

Answer 3

Tùy thuộc. Bạn càng nhấn db, bạn càng có nhiều tải. Chỉ cần một số điều cần tìm. Nếu bạn cần hiển thị các giá trị từ nhiều bảng khác nhau, có thể bạn sẽ cần chạy một số truy vấn. Nếu bạn chỉ có một vài người dùng và bạn biết bạn sẽ không có nhiều dữ liệu, điều đó có thể không quan trọng.

Một số điều cần xem xét:

• bạn đang chạy cùng một truy vấn nhiều lần mỗi tải trang? Nếu bạn có thể tái sử dụng kết quả, hãy làm điều đó.
• Bạn có đang chạy truy vấn cho mỗi kết quả của truy vấn khác không? Nếu có, có thể cho phép DB thực hiện phép nối và chỉ thực hiện một lần kéo.

Nếu trang của bạn chậm đánh quá nhiều db, hãy xem memcached.

Answer 4

Bạn có thể thử tính lại mã của mình theo thời gian để giảm số lượng chuyến đi khứ hồi sang SQL Server. Một cách để làm điều này có thể là sử dụng bộ nhớ đệm.Ví dụ, dữ liệu bạn cần thường xuyên có thể được tải khi ứng dụng được bắt đầu, sau đó lấy từ bộ nhớ cache khi nó là cần thiết.

Một cách tiếp cận khác có thể là khử bình thường dữ liệu của bạn thành các bảng được thiết kế đặc biệt để cung cấp cho bạn dữ liệu mà trang web của bạn cần trong một số lượng truy vấn ít hơn.

Answer 5

Cũng nên xem xét nếu một số truy vấn đó (ví dụ như những truy vấn bạn sử dụng để điền giá trị tra cứu) có thể được lưu trong bộ nhớ cache. Bằng cách đó, nếu cùng một truy vấn được gọi trên nhiều trang hoặc mỗi lần bạn di chuyển từ một nhóm hồ sơ này sang một nhóm khác, cơ sở dữ liệu không được nhấn lần nữa để chạy exaclty cùng một truy vấn. Tôi nhớ một lần chúng tôi đã cố gắng xác định lý do tại sao trang web quá chậm khi proc được lưu trữ chạy rất nhanh và được tìm thấy bằng cách sử dụng profiler mà nó đã được gửi đi lặp đi lặp lại khi nó không cần thiết.

Answer 6

Bạn có thể lưu tất cả các truy vấn đó bằng vbulletin. Nếu bạn xem pbnation.com, họ có hơn một triệu khách truy cập mỗi ngày và chỉ khoảng 3-4 truy vấn trên mỗi lần tải trang. Mọi thứ khác được lưu trữ trong memcached.