problem:
What is an index?
How does indexing work?
The role of the index:
Index is to improve the efficiency of data query
One of the core concepts of database processing data:
The core of the underlying storage of the database is based on these data models. Every time we encounter a new database, we need to pay attention to its data model first, so that we can theoretically analyze the applicable scenarios of this database.
Indexed model (data structure that improves the efficiency of reading and writing data):
Hash table: A data structure stored as a key value (key: value), use the key to find the value (dict)
Idea: Put the value in an array, use the hash function to convert the key to a coordinate, and then put the value at the coordinate of the array.
Implementation steps: first calculate the position of the key through the hash function; then traverse in order to find the value.
Excellent: The key value is not incremental, and the speed of adding a new dictionary will be very fast
Disadvantage: Because it is out of order, the hash index is very slow for interval query.
Example: If you want to find all the values between [key1 ~ key5], you need to scan them all.
Applicable scenarios: This structure of the hash table is suitable for scenarios where there are only equivalent queries (Memcached and some other NoSQL engines)
Note: The location of the hash of different keys may be the same, so it will be followed by a linked list. The linked list is composed of a separate dictionary (user).
Ordered array:
Idea: Dichotomy, because it is ordered, you can query the intermediate value, exclude half of the keys, and so on
Steps:
The key value is not repeated: dichotomy
Interval query: [key1 ~ key5] first find key1 by dichotomy (if it does not exist, find the first value greater than key1), and then traverse to the right to find the value greater than key5
Excellent: High query efficiency
Poor: Big cost of updating data
Example: If you need to insert a record in the middle, you must move all subsequent records
Applicable scenarios: The performance of ordered arrays in the equivalent query and range query scenarios is very good (for static storage engines)
Search tree (binary search tree):
Idea: The left son of each node is smaller than the parent node, and the parent node is smaller than the right son (the size of the son increases from left to right)
Implementation steps: each node is equivalent to making a judgment, using the judgment result to select the correct path
Excellent: The search efficiency is the highest, and the time complexity of query and update is O (log (N))
Poor: Although the efficiency is high, the query time is actually very slow
Because: the index is not only stored in memory, but also written to disk
Example: You can imagine a balanced binary tree with 1 million nodes and a tree height of 20. A query may require access to 20 data blocks. In the era of mechanical hard drives, it takes about 10 ms of addressing time to randomly read a data block from the disk. In other words, for a 1 million row table, if you use a binary tree to store, it may take 20 10 ms to access a row separately
Applicable scenarios: Most database storage does not use binary trees
Note: The N-ary tree model is widely used to increase the number of sons of each node of the binary tree (N depends on the data block size) to reduce the average number of disk accesses
InnoDB's index model:
Table storage method: According to the order of the primary key stored in the form of an index, this storage method table is called the index organization table.
Index model used: InnoDB uses the B + tree index model, so the data is stored in the B + tree. Each index corresponds to a B + tree in InnoDB.
example:
Suppose, we have a table with a primary key column ID, with a field k in the table, and an index on k.
create table T(id int primary key, k int not null, name varchar(16),index (k))engine=InnoDB;
The (ID, k) values of R1 ~ R5 in the table are (100,1), (200,2), (300,3), (500,5), and (600,6), respectively. as follows
The index types in the figure are divided into:
Primary key index: The leaf node of the primary key index stores the entire row of data. In InnoDB, the primary key index is also called a clustered index.
Non-primary key index: The content of the leaf node of the non-primary key index is the value of the primary key. In InnoDB, non-primary key indexes are also called secondary indexes.
The difference between the two:
① If the statement is select * from T where ID = 500, which is the primary key query method, you only need to search the ID B + tree;
②If the statement is select * from T where k = 5, that is, the common index query method, you need to search the k index tree first to get the ID value of 500, and then search the ID index tree again. This process is called back to the table.
to sum up:
Non-primary key index queries need to scan an index tree, so try to use the primary key index in the query.
Index maintenance:
In order to maintain the order of the index, necessary maintenance must be done when inserting data.
Increase in order: just insert a new record after the largest row
Insert in the middle: need to logically move the data behind to make room
The current data page is full: the page is split, apply for a new data page, and move part of the data to the past. PS: This operation will affect performance and data page utilization
Page merge: the reverse process of page splitting
The self-incrementing primary key refers to the primary key defined on the self-incrementing column, which is generally defined in the table-building statement: NOT NULL PRIMARY KEY AUTO_INCREMENT.
Self-increasing primary key scenario: under normal circumstances, it is recommended to create an self-increasing primary key, so that the non-primary key index takes up the least space
Non-incrementing primary key scenario: field with business logic, field type with too long value
Exception: some fields with business logic can also be used as primary keys (KV scenario)
1. There is only one index
2. The index must be a unique index
Since there is no other index, there is no need to consider the size of the leaf nodes of other indexes.
PS: The smaller the length of the primary key, the smaller the leaf node of the ordinary index, and the smaller the space occupied by the ordinary index.