count (1) than the count (*) high efficiency it
Where there are conditions count, it will count the number of rows according to all scan code results, its performance is more dependent on your Where conditions
MyISAM engine will list a number of rows of records down, so when the execution count (*) will return the number of direct, high efficiency.
After the default MySQL 5.5 engine is switched to InnoDB, InnoDB because of the increased version control (MVCC) reasons, there are multiple transactions at the same time there is a time to access data and update operations, each transaction needs to maintain his visibility, then each transaction the number of rows to the query is different, so you can not cache a specific number of lines, every time he needs to count the number of rows at all.
The official explanation
InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference.
InnoDB processing SELECT COUNT (*) and SELECT COUNT (1) using the operation mode Rong Yang, no substantial difference between the two
count definition
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.
Returns non-NULL value count SELECT statement to retrieve the row expr
That is the COUNT aggregate function, the SELECT result set is counted, but the parameters need not NULL
COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.
count ( ) different, he does not care about the return value is calculated his count will be empty, because the count (1) 1 is a constant true expression, count ( ) or count (1) is the set of all results conduct count, so they are essentially no different
InnoDB optimization
The place itself InnoDB has done some optimization, it uses a minimum of two indexes to the query optimization count. If there is no secondary index will choose a clustered index, this design is a single IO from the perspective of saving a lot of overhead
COUNT (column) will also traverse the entire table, but the difference is that it will get the value after the determination of whether the air column, then accumulated, so if the need to resolve the primary key for the content, if it is necessary according to a secondary index again primary key access to content, but also a IO operation, the performance of count (column) is certainly not as good as the first two
count(*)=count(1)>count(primary key)>count(column)
count (*) in the query depends on all data sets, we also need to try to circumvent the full amount count, we query to make the appropriate buffer for the foreseeable count, may be Redis, can also be a separate MySQL count table, of course, no matter which is the way we need to consider the issue of consistency.
Other derivative point article
What is mvcc
Multi-version concurrency control, optimistic locking in an implementation
MVCC is mainly in place for the next Repeatable-Read (Repeatable read) transaction isolation level to do, in most cases a row lock, to achieve non-blocking read, read not locked, read and write do not conflict. But every rows require additional storage space, need to do more line maintenance and inspection work
Read transaction under MVCC concurrency control is generally used == == stamp or mark the transaction ID to read the current state of the database. Reading and writing coexist when the write operation will be based on the current state of the database, create a new version, concurrent read access is still the old version of Data
MVCC is to use the same data and temporary way of multi-mode version, concurrency control to ensure a read transaction will never be blocked
The most basic row innodb storage contains some additional store information, MVCC relevant are: DB_TRX_ID, DB_ROLL_PTR, DB_ROW_ID
DB_TRX_ID insert or update rows last transaction transaction identifier
DB_ROLL_PTR rollback undo log records written before looking version of the data is through this
DB_ROW_ID row ID. This is used to index them
DB_TRX_ID records the time lines created
When operating in insert, "creation time" = DB_TRX_ID. "Delete No";
When operating in the update, copy the "creation time" new line = DB_TRX_ID, no time to delete the old data rows "creation time" constant, time = delete the transaction DB_TRX_ID;
When delete operation "create time" corresponding rows of the same, delete = DB_ROW_ID time of the transaction;
During the select operation, no modifications to both the read-only data corresponding
What is the minimum secondary index
Secondary index is included in each leaf node of the index column is not the primary key, this index is followed by the primary key column
Why require two secondary index index?
Saved secondary index leaf node is not the physical location of a pointer to the row, but the primary key of the row, so the two need to find an index in a clustered index.
Leaf node stores the master key purposes:
Reduced when there is line or mobile data division maintenance of the secondary index. Using the primary key values as a pointer to make secondary indexes take up more space, but in return when moving without the renewal of secondary indexes primary key pointer.
What is the clustered index
InnoDB clustered index actually preserved and index B-Tree data structure in the same row. Clustered indexes can be understood as a complete database table data
Each table has a clustered index, and only one
Clustered indexes advantages:
- Save the data together
- Faster data access
- Use a covering index scan query can be used directly in the primary key node page
Clustered index drawbacks:
- Insertion speed dependent intervening sequence
- The full table scan slows down
- Update column costly clustered index (primary key)
How to ensure data consistency
Distributed Transaction
What is a distributed transaction? How to implement distributed transactions?
The other from an article