Đếm (*) so với Đếm (1) - Máy chủ SQL

Chỉ cần tự hỏi nếu bất kỳ ai trong số bạn sử dụng Count(1)hơn Count(*)và nếu có một sự khác biệt đáng chú ý trong hiệu suất hoặc nếu đây chỉ là một thói quen di sản đã được đưa ra từ những ngày đã qua?

Cơ sở dữ liệu cụ thể là SQL Server 2005.

Không có sự khác biệt.

Lý do:

Sách trực tuyến nói " COUNT ( { [ [ ALL | DISTINCT ] expression ] | * } )"

"1" là một biểu thức không null: vì vậy nó giống như COUNT(*). Trình tối ưu hóa nhận ra nó cho những gì nó là: tầm thường.

Giống như EXISTS (SELECT * ...hoặcEXISTS (SELECT 1 ...

Thí dụ:

SELECT COUNT(1) FROM dbo.tab800krows
SELECT COUNT(1),FKID FROM dbo.tab800krows GROUP BY FKID

SELECT COUNT(*) FROM dbo.tab800krows
SELECT COUNT(*),FKID FROM dbo.tab800krows GROUP BY FKID

Cùng IO, cùng kế hoạch, công trình

Chỉnh sửa, tháng 8 năm 2011

Câu hỏi tương tự trên DBA.SE .

Chỉnh sửa, tháng 12 năm 2011

COUNT(*)được đề cập cụ thể trong ANSI-92 (tìm " Scalar expressions 125")

Trường hợp:

a) Nếu COUNT (*) được chỉ định, thì kết quả là giá trị chính của T.

Đó là, tiêu chuẩn ANSI công nhận nó là chảy máu rõ ràng những gì bạn có ý nghĩa. COUNT(1)đã được các nhà cung cấp RDBMS tối ưu hóa vì sự mê tín này. Nếu không, nó sẽ được đánh giá theo ANSI

b) Mặt khác, đặt TX là bảng một cột là kết quả của việc áp dụng <biểu thức giá trị> cho mỗi hàng của T và loại bỏ các giá trị null. Nếu một hoặc nhiều giá trị null bị loại bỏ, thì một điều kiện hoàn thành sẽ được đưa ra: cảnh báo-

Trong SQL Server, các câu lệnh này mang lại cùng một kế hoạch.

Trái với ý kiến ​​phổ biến, trong Oracle họ cũng vậy.

SYS_GUID() trong Oracle là chức năng chuyên sâu khá tính toán.

Trong cơ sở dữ liệu thử nghiệm của tôi, t_evenlà một bảng có 1,000,000các hàng

Truy vấn này:

SELECT  COUNT(SYS_GUID())
FROM    t_even

chạy trong 48vài giây, vì hàm cần đánh giá từng SYS_GUID()trả về để đảm bảo rằng nó không phải là a NULL.

Tuy nhiên, truy vấn này:

SELECT  COUNT(*)
FROM    (
        SELECT  SYS_GUID()
        FROM    t_even
        )

chạy trong 2vài giây, vì nó thậm chí không cố gắng đánh giá SYS_GUID()(mặc dù *là đối số COUNT(*))

Rõ ràng, COUNT(*)và COUNT(1)sẽ luôn trả lại kết quả tương tự. Do đó, nếu cái này chậm hơn cái kia thì có hiệu quả là do lỗi tối ưu hóa. Vì cả hai hình thức được sử dụng rất thường xuyên trong các truy vấn, nên sẽ không có ý nghĩa gì khi DBMS cho phép một lỗi như vậy không bị trộn lẫn. Do đó, bạn sẽ thấy rằng hiệu suất của cả hai hình thức là (có thể) giống hệt nhau trong tất cả các DBMS SQL chính.

Tôi làm việc trong nhóm SQL Server và tôi hy vọng có thể làm rõ một vài điểm trong luồng này (tôi chưa thấy nó trước đây, vì vậy tôi xin lỗi nhóm kỹ thuật đã không làm như vậy trước đây).

Thứ nhất, không có sự khác biệt về ngữ nghĩa giữa select count(1) from tablevs select count(*) from table. Họ trả lại kết quả tương tự trong tất cả các trường hợp (và đó là một lỗi nếu không). Như đã lưu ý trong các câu trả lời khác, select count(column) from tablelà khác nhau về mặt ngữ nghĩa và không phải lúc nào cũng trả lại kết quả giống như count(*).

Thứ hai, liên quan đến hiệu suất, có hai khía cạnh quan trọng trong SQL Server (và SQL Azure): công việc thời gian biên dịch và công việc thời gian thực hiện. Công việc thời gian biên dịch là một lượng nhỏ công việc phụ trong quá trình thực hiện hiện tại. Có một sự mở rộng của * cho tất cả các cột trong một số trường hợp theo sau là giảm trở lại 1 cột do đầu ra của một số hoạt động nội bộ trong ràng buộc và tối ưu hóa. Tôi nghi ngờ nó sẽ xuất hiện trong bất kỳ thử nghiệm có thể đo lường nào và nó có thể bị lạc trong tiếng ồn của tất cả những thứ khác xảy ra dưới vỏ bọc (chẳng hạn như thống kê tự động, phiên xevent, phí lưu trữ truy vấn, trình kích hoạt, v.v.). Nó có thể là một vài ngàn hướng dẫn CPU thêm. Vì thế, Count (1) thực hiện công việc ít hơn một chút trong quá trình biên dịch (điều này thường sẽ xảy ra một lần và kế hoạch được lưu trữ trong nhiều lần thực hiện tiếp theo). Đối với thời gian thực hiện, giả sử các kế hoạch là như nhau nên không có sự khác biệt có thể đo lường được. (Một trong những ví dụ trước đây cho thấy sự khác biệt - rất có thể là do các yếu tố khác trên máy nếu kế hoạch giống nhau).

Làm thế nào để kế hoạch có thể có khả năng khác nhau. Điều này cực kỳ khó xảy ra, nhưng nó có khả năng trong kiến ​​trúc của trình tối ưu hóa hiện tại. Trình tối ưu hóa của SQL Server hoạt động như một chương trình tìm kiếm (nghĩ: chương trình máy tính chơi cờ tìm kiếm thông qua các phương án khác nhau cho các phần khác nhau của truy vấn và bỏ ra các phương án để tìm kế hoạch rẻ nhất trong thời gian hợp lý). Tìm kiếm này có một vài giới hạn về cách thức hoạt động để giữ cho quá trình biên dịch truy vấn kết thúc trong thời gian hợp lý. Đối với các truy vấn vượt quá tầm thường nhất, có các giai đoạn tìm kiếm và chúng xử lý các đợt truy vấn dựa trên mức độ tốn kém của trình tối ưu hóa cho rằng truy vấn có khả năng thực thi. Có 3 giai đoạn tìm kiếm chính, và mỗi giai đoạn có thể chạy các heuristic tích cực hơn (tốn kém) cố gắng tìm một kế hoạch rẻ hơn bất kỳ giải pháp nào trước đó. Cuối cùng, có một quá trình quyết định vào cuối mỗi giai đoạn cố gắng xác định liệu nó sẽ trả lại kế hoạch mà nó tìm thấy cho đến nay hay nó nên tiếp tục tìm kiếm. Quá trình này sử dụng tổng thời gian thực hiện cho đến nay so với chi phí ước tính của kế hoạch tốt nhất được tìm thấy cho đến nay. Vì vậy, trên các máy khác nhau có tốc độ CPU khác nhau, mặc dù có thể có các kế hoạch khác nhau do hết thời gian trong giai đoạn trước với kế hoạch so với tiếp tục vào giai đoạn tìm kiếm tiếp theo. Ngoài ra còn có một vài tình huống tương tự liên quan đến việc hết thời gian của giai đoạn trước và có khả năng hết bộ nhớ đối với các truy vấn rất, tốn kém tiêu tốn tất cả bộ nhớ trên máy (thường không phải là sự cố trên 64 bit nhưng đó là vấn đề lớn hơn trở lại máy chủ 32 bit). Cuối cùng, nếu bạn nhận được một kế hoạch khác, hiệu suất trong thời gian chạy sẽ khác nhau. Tôi không

Net-net: Vui lòng sử dụng bất cứ điều gì trong hai bạn muốn vì không có vấn đề nào trong bất kỳ hình thức thực tế nào. (Thành thật, có nhiều yếu tố lớn hơn nhiều ảnh hưởng đến hiệu suất trong SQL ngoài chủ đề này).

Tôi hi vọng cái này giúp được. Tôi đã viết một chương sách về cách trình tối ưu hóa hoạt động nhưng tôi không biết có thích hợp để đăng nó ở đây không (vì tôi vẫn nhận được tiền bản quyền nhỏ từ nó. Vì vậy, thay vì đăng bài tôi sẽ đăng một liên kết tới bài nói chuyện tôi đã đưa ra tại SQLBits ở Anh về cách trình tối ưu hóa hoạt động ở mức cao để bạn có thể xem các giai đoạn chính khác nhau của tìm kiếm chi tiết hơn một chút nếu bạn muốn để tìm hiểu về điều đó. Đây là liên kết video: https://sqlbits.com/Simes/Event6/inside_the_sql_server_query_optimizer

Trong Tiêu chuẩn SQL-92, COUNT(*)cụ thể có nghĩa là "tính chính xác của biểu thức bảng" (có thể là bảng cơ sở, `XEM, bảng dẫn xuất, CTE, v.v.).

Tôi đoán ý tưởng đó COUNT(*)là dễ dàng để phân tích. Sử dụng bất kỳ biểu hiện khác đòi hỏi sự phân tích cú pháp để đảm bảo nó không tham khảo bất kỳ cột ( COUNT('a')nơi alà một chữ và COUNT(a)nơi alà một cột có thể mang lại kết quả khác nhau).

Trong cùng một hướng, COUNT(*)có thể dễ dàng chọn ra bởi một lập trình viên con người quen thuộc với các Tiêu chuẩn SQL, một kỹ năng hữu ích khi làm việc với nhiều sản phẩm SQL của một nhà cung cấp.

Ngoài ra, trong trường hợp đặc biệt SELECT COUNT(*) FROM MyPersistedTable;, suy nghĩ là DBMS có khả năng giữ số liệu thống kê về tính chính xác của bảng.

Do đó, vì COUNT(1)và COUNT(*)tương đương về mặt ngữ nghĩa, tôi sử dụng COUNT(*).

COUNT(*)và COUNT(1)giống nhau trong trường hợp kết quả và hiệu suất.

Tôi hy vọng trình tối ưu hóa sẽ đảm bảo không có sự khác biệt thực sự bên ngoài các trường hợp cạnh kỳ lạ.

Như với bất cứ điều gì, cách thực sự duy nhất để nói là đo các trường hợp cụ thể của bạn.

Điều đó nói rằng, tôi đã luôn luôn sử dụng COUNT(*).

Khi câu hỏi này xuất hiện nhiều lần, đây là một câu trả lời nữa. Tôi hy vọng sẽ thêm một cái gì đó cho người mới bắt đầu tự hỏi về "thực hành tốt nhất" ở đây.

SELECT COUNT(*) FROM something đếm hồ sơ đó là một nhiệm vụ dễ dàng.

SELECT COUNT(1) FROM something lấy 1 trên mỗi bản ghi và hơn số 1 không phải là null, về cơ bản là đếm các bản ghi, chỉ phức tạp hơn.

Đã nói điều này: dbms tốt lưu ý rằng câu lệnh thứ hai sẽ dẫn đến cùng số lượng với câu lệnh đầu tiên và diễn giải lại nó cho phù hợp, như không làm những việc không cần thiết. Vì vậy, thông thường cả hai câu lệnh sẽ dẫn đến cùng một kế hoạch thực hiện và mất cùng một lượng thời gian.

Tuy nhiên từ điểm dễ đọc, bạn nên sử dụng câu lệnh đầu tiên. Bạn muốn đếm hồ sơ, vì vậy đếm hồ sơ, không phải biểu thức. Chỉ sử dụng COUNT (biểu thức) khi bạn muốn đếm số lần xuất hiện không phải là thứ gì đó.

Tôi đã chạy thử nghiệm nhanh trên SQL Server 2012 trên hộp hyper-v RAM 8 GB. Bạn có thể xem kết quả cho chính mình. Tôi đã không chạy bất kỳ ứng dụng cửa sổ nào khác ngoài SQL Server Management Studio trong khi chạy các thử nghiệm này.

Lược đồ bảng của tôi:

CREATE TABLE [dbo].[employee](
    [Id] [bigint] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_employee] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

Tổng số bản ghi trong Employeebảng: 178090131 (~ 178 triệu hàng)

Truy vấn đầu tiên:

Set Statistics Time On
Go    
Select Count(*) From Employee
Go    
Set Statistics Time Off
Go

Kết quả của truy vấn đầu tiên:

 SQL Server parse and compile time: 
 CPU time = 0 ms, elapsed time = 35 ms.

 (1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 10766 ms,  elapsed time = 70265 ms.
 SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Truy vấn thứ hai:

    Set Statistics Time On
    Go    
    Select Count(1) From Employee
    Go    
    Set Statistics Time Off
    Go

Kết quả của truy vấn thứ hai:

 SQL Server parse and compile time: 
   CPU time = 14 ms, elapsed time = 14 ms.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 11031 ms,  elapsed time = 70182 ms.
 SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Bạn có thể nhận thấy có sự khác biệt 83 (= 70265 - 70182) mili giây có thể dễ dàng được quy cho tình trạng hệ thống chính xác tại thời điểm truy vấn được chạy. Ngoài ra tôi đã thực hiện một lần chạy, vì vậy sự khác biệt này sẽ trở nên chính xác hơn nếu tôi thực hiện một vài lần chạy và thực hiện một số phép tính trung bình. Nếu với tập dữ liệu khổng lồ như vậy, sự khác biệt sẽ đến dưới 100 mili giây, thì chúng ta có thể dễ dàng kết luận rằng hai truy vấn không có bất kỳ sự khác biệt về hiệu năng nào được trình bày bởi SQL Server Engine.

Lưu ý : RAM đạt mức sử dụng gần 100% trong cả hai lần chạy. Tôi đã khởi động lại dịch vụ SQL Server trước khi bắt đầu cả hai lần chạy.

SET STATISTICS TIME ON

select count(1) from MyTable (nolock) -- table containing 1 million records. 

Thời gian thực thi máy chủ SQL:
Thời gian CPU = 31 ms, thời gian trôi qua = 36 ms.

select count(*) from MyTable (nolock) -- table containing 1 million records. 

Thời gian thực thi của máy chủ SQL:
Thời gian CPU = 46 ms, thời gian trôi qua = 37 ms.

Tôi đã chạy nó hàng trăm lần, xóa bộ nhớ cache mỗi lần .. Kết quả thay đổi theo thời gian khi tải máy chủ thay đổi, nhưng hầu như luôn count(*)có thời gian cpu cao hơn.

Có một bài viết cho thấy rằng COUNT(1)trên Oracle chỉ là một bí danh COUNT(*), với một bằng chứng về điều đó.

Tôi sẽ trích dẫn một số phần:

Có một phần của phần mềm cơ sở dữ liệu được gọi là Phần mềm Tối ưu hóa, được định nghĩa trong tài liệu chính thức là Phần mềm cơ sở dữ liệu được tích hợp sẵn để xác định cách hiệu quả nhất để thực thi câu lệnh SQL.

Một trong những thành phần của trình tối ưu hóa được gọi là Thay đổi biến đổi, có vai trò là xác định xem có thuận lợi để viết lại câu lệnh SQL gốc thành câu lệnh SQL tương đương về mặt ngữ nghĩa có thể hiệu quả hơn không.

Bạn có muốn xem trình tối ưu hóa làm gì khi bạn viết truy vấn bằng COUNT (1) không?

Với người dùng có ALTER SESSIONđặc quyền, bạn có thể đặt tracefile_identifier, bật theo dõi trình tối ưu hóa và chạy phần COUNT(1)chọn, như : SELECT /* test-1 */ COUNT(1) FROM employees;.

Sau đó, bạn cần bản địa hóa các tệp theo dõi, những gì có thể được thực hiện với SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';. Sau đó trên tệp, bạn sẽ tìm thấy:

SELECT COUNT(*) “COUNT(1)” FROM “COURSE”.”EMPLOYEES” “EMPLOYEES”

Như bạn có thể thấy, nó chỉ là một bí danh cho COUNT(*).

Một nhận xét quan trọng khác: COUNT(*)đã thực sự nhanh hơn hai thập kỷ trước trên Oracle, trước Oracle 7.3:

Count (1) đã được viết lại trong Count (*) kể từ 7.3 vì Oracle thích Tự động điều chỉnh các tuyên bố thần thoại. Trong Oracle7 trước đó, oracle đã phải đánh giá (1) cho mỗi hàng, như là một hàm, trước khi DETERMINISTIC và NON-DETERMINISTIC tồn tại.

Vì vậy, hai thập kỷ trước, đếm (*) đã nhanh hơn

Đối với một cơ sở dữ liệu khác là Sql Server, nó cần được nghiên cứu riêng cho từng cơ sở dữ liệu.

Tôi biết rằng câu hỏi này là dành riêng cho Sql Server, nhưng các câu hỏi khác về SO về cùng một chủ đề, không đề cập đến cơ sở dữ liệu, đã bị đóng và được đánh dấu là trùng lặp từ câu trả lời này.

Trong tất cả RDBMS, hai cách đếm tương đương nhau về kết quả mà chúng tạo ra. Về hiệu năng, tôi không quan sát thấy bất kỳ sự khác biệt về hiệu năng nào trong SQL Server, nhưng có thể đáng để chỉ ra rằng một số RDBMS, ví dụ PostgreQuery 11, có các triển khai ít tối ưu hơn COUNT(1)khi chúng kiểm tra tính không thể thấy của biểu thức đối số trong bài viết này .

Tôi đã tìm thấy chênh lệch hiệu suất 10% cho các hàng 1M khi chạy:

-- Faster
SELECT COUNT(*) FROM t;

-- 10% slower
SELECT COUNT(1) FROM t;

COUNT (1) không khác biệt đáng kể so với COUNT (*), nếu có. Đối với câu hỏi của COUNTing NULLable COLUMNs, điều này có thể đơn giản để giới thiệu sự khác biệt giữa COUNT (*) và COUNT (<some col>) -

USE tempdb;
GO

IF OBJECT_ID( N'dbo.Blitzen', N'U') IS NOT NULL DROP TABLE dbo.Blitzen;
GO

CREATE TABLE dbo.Blitzen (ID INT NULL, Somelala CHAR(1) NULL);

INSERT dbo.Blitzen SELECT 1, 'A';
INSERT dbo.Blitzen SELECT NULL, NULL;
INSERT dbo.Blitzen SELECT NULL, 'A';
INSERT dbo.Blitzen SELECT 1, NULL;

SELECT COUNT(*), COUNT(1), COUNT(ID), COUNT(Somelala) FROM dbo.Blitzen;
GO

DROP TABLE dbo.Blitzen;
GO