The count in the SQL statement

In cases where null is not considered, if NULL participates in the aggregation operation, the aggregate function except COUNT (*) ignores null.
Count (1) and count (primary key) both scan the primary key index to get the data,
COUNT (*) is the scan table.
So the count (1) and the count (primary key) are both highly efficient.
Another way to do this is count (ROWID), which is also only scan index, high efficiency.

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.

Count (GO) in SQL statement