Mysql--InnoDB engine summary

Every back-end programmer should know something about the InnoDb engine of the Mysql database. This article is based on "MySql Technology Insider-InnoDB Storage Engine", summarizes and refines, in order to quickly grasp its core points.

1. Features

1. The first MySQL storage engine that fully supports ACID transactions. BDB is the first MySQL storage engine that supports transactions. Development has been stopped

2. High availability, high performance, high expansion

Two, version

Old version of InnoDB: support ACID, row lock design, MVCC

InnoDB 1.0.x: add compress and dynamic page formats

InnoDB 1.1.x: Added Linux AIO, multiple rollback segments

InnoDB 1.2.x: Added full-text index support, online index addition

Three, index

1. The leaf nodes of the clustered index store row data, not pointers to target data

2. The leaf nodes of the clustered index are not physically continuous, but they are logically continuous through double-linked list links

3. The leaf node of the auxiliary index saves the auxiliary index key and the primary index key of the record. When searching for the record through the auxiliary index, first find the auxiliary index B+ tree, and then find the main index B+ tree according to the obtained primary index key value , And finally get the entire row of data

4. There are two cases of B+ tree splitting: random insertion and same direction insertion. In terms of random insertion, the split of the B+ tree is no different from the regular B+ tree. However, when the B+ tree is inserted in one direction (increment/decrement), there is often a waste of space. Therefore, InnoDB has made a little optimization. When facing a split, it moves the insertion point into a new leaf node, and all the nodes in front of it remain intact.

5. B+ tree index creation and deletion are expensive, and the optimization scheme: Fast Index CreationOnline DDLOnline DML

6. Cardinality value, you can view the Cardinality value of a table through the show index from (table) command. This attribute is an estimate of the number of different key values ​​that the index depends on. Eight leaf nodes of the index B+ tree are sampled and estimated, and the number of different key values ​​is counted, added, divided by 8, and multiplied by the leaf node The total is obtained. Generally speaking, if the Cardinality on an index is relatively small, it means that the index search efficiency will be very low (the repetition rate is too high), and it is not recommended to use the index, and vice versa.

7. Covering index and back table. As mentioned above, InnoDB's auxiliary index usually needs to query the B+ index tree twice to find the target row, that is, after searching the auxiliary index B+ tree once, after finding the primary key, query the primary index B+ tree, which is the table back operation. The table-back operation increases the system IO. If the table-back operation can be reduced, the query efficiency will be improved, so the covering index appears.

   ​ Covering index means that if you can directly obtain the value of the returned column during a query of the auxiliary index, then you will no longer query the main index B+ tree.

   ​ For example, on the table student (id, name, sex), the id is the primary key, the name is the key, that is, a clustered index is established on the id and a secondary index is established on the name

   ​ For queries select id,name from student where name = 'Bryant', the leaf nodes of the auxiliary index can directly return the values ​​of the id and name columns, and the covering index can be used instead of returning to the table

   ​ For select id,name,sex from student where name = 'Bryant'the leaf node of the auxiliary index does not store the value of sex, it must be queried back to the table. Optimization plan: establish a joint index (name, sex)

8. Application of covering index:

   1. Query optimization of full table count on auxiliary index columns
   2. Column query back to table optimization (as described in 7)
   3. Paging query

9. The special case of not taking the index: If the range query is performed on the auxiliary index column and the covering index cannot be used, the query efficiency will be very low: first find the primary key of the row matching the required range through the auxiliary index, and then find the primary index B+ tree , At this time has become a discrete query. Therefore, even if there is an auxiliary index on the judgment attribute of where, the optimizer will choose not to take the auxiliary index and replace it with the primary index query