The difference between count (*), COUNT (1), and count (primary key)

If NULL participates in the aggregation operation, all other aggregation functions except count (*) ignore null. Such as:

ID DD

1 E

2 NULL

Select COUNT (*) from table--the result is 2

Select COUNT (DD) from table---result is 1

Efficiency issues:

When the table has a larger amount of data, using count (1) is more than using count (*) when analyzing the table.

The effect of count (1) and COUNT (*) is the same from the execution plan.

However, after the table has been analyzed, COUNT (1) will be less than COUNT (*) (within 1w of data), but not much.

This is also related to the number of records in the table! If the amount of data outside of 1w has been analyzed by the table, the Count (1) is more than count (*).

Also, using count (1) is a little bit less than using count (*) when the amount of data reaches more than 10w.

If your data table does not have a primary key, then count (1) is faster than COUNT (*)

If there is a primary key, then the primary key (the Federated primary key) as the count condition is also faster than COUNT (*)

If your table has only one field, then count (*) is the quickest.

COUNT (*) count (1) compares the two. The data field that corresponds to count (1) is mostly still.

If Count (1) is a clustered index, ID, that must be count (1) fast. But the difference is very small.

Because Count (*), automatically optimizes the specified field to that one. So no need to go to count (1), with Count (*), SQL will help you to complete the optimized

So: Count (1) and COUNT (*) are basically no different!

SQL tuning is primarily about reducing the number of consistent gets and physical reads.

The difference between count (*), COUNT (1), and count (primary key)