COUNT nhanh hơn kéo các bản ghi và đếm trong mã?

Question

Đây là tình hình:

1. đầu tiên tôi cần phải chạy một truy vấn để biết có bao nhiêu hồ sơ tồn tại.

   Ví dụ: SELECT COUNT(DISTINCT userid) from users;

2. Thường thì điều này sẽ là tất cả những gì cần thiết. Tuy nhiên, đôi khi (nói 30% thời gian) theo truy vấn đầu tiên, người dùng sẽ muốn chạy truy vấn thứ hai, ghi chi tiết các bản ghi.

   Ví dụ: SELECT * FROM users;

Có bất kỳ lý do gì để chạy SELECT COUNT ban đầu thay vì chỉ SELECT? Tức là, làm cho số lượng bản ghi trong SQL nhanh hơn thực tế kéo các bản ghi trở lại? Hoặc là nó làm cơ bản cùng một công việc một trong hai cách và vì vậy tôi nên tránh làm hai truy vấn?

Nói cách khác, tốt hơn là luôn luôn kéo các bản ghi trong truy vấn đầu tiên (không sử dụng COUNT), sau đó đếm các bản ghi trong mã (Java). Nếu người dùng muốn chạy truy vấn thứ hai, thì tuyệt vời, tôi đã có dữ liệu. Nếu không, sau đó chỉ cần đổ nó.

Thực tiễn tốt nhất ở đây là gì?

Answer 1

Nếu bạn biết mình cần dữ liệu, hãy tiếp tục và kéo nó và đếm nó trong mã. Tuy nhiên, nếu bạn chỉ cần đếm, nó nhanh hơn đáng kể để kéo số lượng từ cơ sở dữ liệu hơn là để thực sự truy xuất các hàng. Ngoài ra nó là thực hành tiêu chuẩn để chỉ kéo những gì bạn cần.

Ví dụ: nếu bạn đang đếm tất cả các hàng trong bảng, hầu hết các triển khai cơ sở dữ liệu không cần xem bất kỳ hàng nào. Các bảng biết có bao nhiêu hàng. Nếu truy vấn có các bộ lọc trong mệnh đề where và nó có thể sử dụng một chỉ mục, nó sẽ không cần phải xem xét dữ liệu của các hàng thực tế, chỉ đếm các hàng từ chỉ mục.

Và tất cả điều này sẽ không tính ít dữ liệu được chuyển.

Quy tắc chung về tốc độ cơ sở dữ liệu được tiếp tục và tự mình thử. Quy tắc chung không phải lúc nào cũng là một chỉ báo tốt. Ví dụ, nếu bảng là 10 hàng và chỉ có một vài cột, tôi có thể kéo toàn bộ mọi thứ ra khỏi cơ hội tôi cần nó, vì 2 chuyến đi vòng vào cơ sở dữ liệu sẽ lớn hơn chi phí của truy vấn.

Answer 2

Đó là nhanh hơn bởi vì:

• Cơ sở dữ liệu được thiết kế và viết bằng một cách để làm những việc như thế càng nhanh càng tốt.
• Bạn không phải gửi toàn bộ bảng vào ứng dụng của mình. Chỉ cần một số nguyên thay thế.

Bạn không bao giờ nên gửi toàn bộ bảng và đếm mặt ứng dụng!

Answer 3

Chỉ cần một ý kiến ​​cá nhân:

Nếu bạn truy vấn "chi tiết" là không cần thiết trên 100% các trường hợp, sau đó nó làm cho tinh thần để sử dụng chức năng count() của MySQL. Nó nhanh hơn và rẻ hơn: MySQL thực hiện nhiệm vụ đếm 'nặng' và gửi một đoạn dữ liệu nhỏ, thay vì gửi một lượng lớn dữ liệu và để ứng dụng của bạn thực hiện nhiệm vụ 'nặng' khi duyệt qua các bản ghi và đếm các hàng.

Điều đó nói rằng, mẹo thông thường: Đảm bảo các bảng của bạn được lập chỉ mục đúng cách, vì vậy truy vấn của bạn chạy tối ưu.

Answer 4

Hai điều cần được xem xét

QUERY # 1

SELECT COUNT(DISTINCT userid) from users; 

Truy vấn này sẽ đi một tổng thể nhanh hơn rất nhiều với một chỉ mục trên userid; Nếu bạn không có một chỉ mục trên userid và không ai trong số các chỉ số bạn đã có bắt đầu với userid, sau đó chạy này

ALTER TABLE user ADD INDEX (userid); 

này sẽ làm cho Query Optimizer chọn để xem xét thông qua các chỉ số rathewr hơn chạm vào bàn.

QUERY # 2

SELECT * from users; 

Tại sao bận tâm để lấy mỗi cột trong mỗi hàng chỉ để đếm số hàng?

Bạn có thể thay thế mà với

SELECT COUNT(id) FROM users; 

nơi id là PRIMARY KEY hoặc

SELECT COUNT(1) FROM users; 

Bạn sẽ phải chuẩn mà truy vấn nhanh, SELECT COUNT(id) hoặc SELECT COUNT(1)

Epilogue

Trừ khi bạn thực sự cần dữ liệu hile đếm, cho phép đếm xảy ra trong Server.