2012-06-07 34 views
8

Vâng, có lẽ tôi đã quá già và tôi muốn hiểu những điều sau đây.Tại sao một công đoàn nhanh hơn một nhóm theo số

truy vấn 1.

select count(*), gender from customer 
group by gender 

truy vấn 2.

select count(*), 'M' from customer 
where gender ='M' 
union 
select count(*), 'F' from customer 
where gender ='F' 

truy vấn 1 là đơn giản, nhưng đối với một số lý do trong các hồ sơ, khi tôi thực hiện cả hai cùng một lúc, nó nói rằng truy vấn 2 sử dụng 39% thời gian và truy vấn 1, 61%.

Tôi muốn hiểu lý do, có thể tôi phải viết lại tất cả các truy vấn của mình.

+1

Chỉ cần đoán: truy vấn thứ hai thực sự không có tổng hợp, và không có trạng thái nào được giữ để tính số đếm (nó chỉ trả về số hàng phù hợp cho 'count (*)') – lanzz

+0

ý của bạn là gì? cùng thời gian'? – Sebas

+2

Tôi đoán bạn chỉ có 2 giới tính và mọi người có giới tính được chỉ định thay vì một số là 'NULL'? Ngoài ra nếu bạn thử 'UNION ALL' thì sao? Liệu điều đó có cải thiện cái thứ hai hơn nữa không? Ngoài ra RDBMS và kế hoạch thực hiện trông như thế nào? Ngoài ra chi phí tương đối trong kế hoạch thực hiện SQL Server không nhất thiết phản ánh hiệu suất thực nếu đó là những gì bạn đang sử dụng để so sánh hai truy vấn. –

Trả lời

5

Truy vấn 2 của bạn thực sự là một mẹo hay. Nó hoạt động như thế này: Bạn có một chỉ số về giới tính. DBMS có thể tìm kiếm trong chỉ mục đó hai lần để nhận được hai dãy các hàng (một cho M và một cho F). Nó không cần phải đọc bất cứ điều gì từ những hàng này, chỉ là chúng tồn tại. Nó có thể đếm số hàng tồn tại trong hai dãy.

Trong truy vấn đầu tiên, DBMS cần giải mã các hàng để đọc giới tính, sau đó nó cần sắp xếp các hàng hoặc xây dựng một Hashtable để tổng hợp chúng. Đó là đắt hơn chỉ cần đếm hàng.

+0

Chỉ mục về giới tính cũng có thể được sử dụng cho luồng tổng hợp trên truy vấn đầu tiên. Không cần sắp xếp như chúng đã có trong thứ tự chỉ mục. –

+0

Đúng, nhưng các hàng cần phải được giải mã và so sánh với nhau. – usr

+0

Các hàng cần được giải mã trong chỉ mục cũng tìm kiếm để nó biết khi nào nó đến hàng cuối cùng khớp với vị từ tìm kiếm và nên ngừng quét. –

0

Tối ưu hóa truy vấn tùy thuộc vào cơ sở dữ liệu. Những gì bạn thấy là cơ sở dữ liệu cụ thể.

Công đoàn, như được viết, sẽ ngây thơ yêu cầu hai thông qua dữ liệu, thực hiện một bộ lọc và đếm. Về cơ bản không có lưu trữ khác là cần thiết.

Tập hợp có thể sắp xếp dữ liệu và sau đó thực hiện đếm. Hoặc, nó có thể tạo ra một bảng băm. Với sự khác biệt về hiệu năng, tôi đoán một loại đang được sử dụng. Rõ ràng, điều này là quá mức cần thiết cho loại truy vấn này.

Nếu bạn có một chỉ số về giới, cả hai phương pháp cơ bản sẽ quét các chỉ số vì vậy hiệu suất nên được tương tự (phiên bản công đoàn có thể quét nó hai lần =.

Liệu các cơ sở dữ liệu mà bạn đang sử dụng cung cấp một cách để Nếu có, bạn nên cập nhật số liệu thống kê và xem liệu bạn có nhận được kết quả tương tự hay không. nhanh hơn cái kia

2

Bạn có chắc chắn không? Có thể là q thứ hai uery chỉ sử dụng tài nguyên được lưu trong bộ nhớ cache từ ngày đầu tiên.

chạy chúng theo hai lô riêng biệt và trước mỗi lần chạy DBCC FREEPROCCACHE để xóa bộ nhớ cache. Sau đó so sánh các giá trị của từng kế hoạch thực hiện.

+1

Đó cũng là dự đoán của tôi – Filip

0

Tôi đã thử một truy vấn tương đương, nhưng tìm thấy kết quả ngược lại; công đoàn mất 65% và 'nhóm theo' mất 35%. (Sử dụng SQL Server 2008). Tôi không có chỉ mục về giới tính vì vậy kế hoạch thực hiện của tôi cho thấy quét chỉ mục nhóm. Trừ khi bạn kiểm tra chi tiết kế hoạch thực hiện, nó thực sự không thể giải thích kết quả này.

Thêm chỉ mục cho truy vấn này có lẽ không phải là một ý tưởng hay vì bạn có thể sẽ không chạy truy vấn này gần như thường xuyên khi bạn định chèn bản ghi vào bảng khách hàng. Trong một số công cụ cơ sở dữ liệu khác với các chỉ mục bitmap (Oracle, PostgreSQL), công cụ cơ sở dữ liệu có thể kết hợp nhiều chỉ mục, để có thể thay đổi tiện ích của các chỉ mục cột đơn.Nhưng trong SQL Server, bạn cần thiết kế các chỉ mục để 'che' các truy vấn thường được sử dụng.

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