I have always thought that count(1) is more effective than count(*), which is despised by my colleagues.

Is MySQL count(1) really faster than count(*)? 

Do you always think like me that count(1) is really faster than count(*)? Suddenly one day I was talking about this with my colleagues, and I was seriously despised.

So have you studied it yourself? If I tell you they are the same, would you believe it?

The count with Where condition will count all the rows according to the scanning result. Its performance is more dependent on your Where condition, so we only explain the situation without Where.

The MyISAM engine will record the total number of rows in a table, so count(*) it will directly return the number during execution  , which is very efficient. After MySQL 5.5, the default engine is switched to InnoDB. Because of the increase of version control (MVCC), when multiple transactions access data and update operations, each transaction needs to maintain its own visibility, then each transaction The number of rows retrieved is also different, so the specific number of rows cannot be cached, and he needs count all the rows each time  . Well  count(1) and  count(*)different?

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference. This is the explanation of the official website. Click to 阅读原文view the official text directly . So the two implementations are actually the same. So why are they the same?

To explore this problem, we first need to understand  count the meaning, the following is the definition given by the official website

Returns a count of the number of non-NULL values of expr in the rows retrieved by a SELECT statement. The result is a BIGINT value.

The rough explanation is to return the count of the non-NULL values ​​of expr in the rows retrieved by the SELECT statement. At this point, we understand that it is an aggregate function, and then the result set of the SELECT is counted, but the parameter is not NULL. Then we continue to read the content of the official website:

COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.

The general content is that count(*) is different. It does not care whether the return value is empty or not. It will calculate his count, because 1 in count(1) is a constant expression, so count(*) is still count(1) ) Is to count all the result sets, so they are essentially the same.

Of course, InnoDB itself has made some optimizations in this place, and it will use the smallest secondary index for  count query optimization. If there is no secondary index, the clustered index will be chosen. This design saves a lot of overhead from the IO perspective alone.

At this point, we understand that count(*) and count(1) are essentially the same. So what is count(column)?

count(column) will also traverse the entire table, but the difference is that it will get the value of the column to determine whether it is empty, and then accumulate, then if the content needs to be parsed for the primary key, if it is secondary, it needs to be based on the primary key again Getting content is another IO operation, so the performance of count(column) is definitely not as good as the previous two. If you compare it in terms of efficiency:count(*)=count(1)>count(primary key)>count(column)

Since count(*) depends on all data sets in query, do we need to avoid the full count as much as possible in design? Usually, we will do appropriate caching for predictable count queries. It can be Redis or a separate MySQL count table. Of course, we need to consider consistency issues in either way.

The article is over here, do you have a new understanding of count()?


往期推荐

Recommend 33 best IDEA configurations, easy to use and fly!


Write like this, it must be spicy chicken code!


Many ways to remove whitespace characters from String! ? The difference is so big!

This article is provided by "Yiban Editor" technical support

 

Facing Java Issue 329: Which command can monitor various operating status information of the virtual machine?

In-depth concurrency Issue 013: Expanding synchronized-lock optimization

If you like this article,

Please press and hold the QR code to follow Hollis. 

Forwarding to the circle of friends is my greatest support.

Click  to see 

Like is a feeling

Watching is a kind of support

↘↘↘

Guess you like

Origin blog.csdn.net/hollis_chuang/article/details/108570817