[MySQL 45 Lecture-5] Lecture 5 - Index

Overview map

05 | Simple Index (Part 2)

example

select * from T where k between 3 and 5 needs to perform several tree search operations?

1. Find the record k=3 on the k index tree and get ID=300;

2. Find R3 corresponding to ID=300 on the primary key index tree;

3. Take the next value k=5 on the k index tree and get ID=500;

4. Go back to the primary key index tree and find R4 corresponding to ID=500;

5. Take the next value k=6 on the k index tree, if the condition is not met, the loop ends.

The query process reads 3 records of the k index tree (steps 1, 3 and 5), and returns to the table twice (steps 2 and 4)

covering index

If the executed statement is select ID from T where k between 3 and 5, you only need to check the ID value, and the ID value is already in the k index tree, so you can directly provide the query result without returning to the table.

• In the query, the index k has covered the query requirements

  • For example, query the primary key ID based on the k index

Since covering indexes can reduce the number of tree searches and significantly improve query performance, using covering indexes is a common performance optimization method

• Is it necessary to create a joint index for ID card and name?

  • If there are high-frequency requests and you need to query the name based on the ID number, this joint index makes sense

leftmost prefix principle

• Indexes such as B+ trees can use the "leftmost prefix" of the index to locate records

• When building a joint index, how to arrange the order of the fields in the index?

  • The evaluation criterion is that the index's reusability

  • priority

    • 1. Establishing a joint index can save one index from maintenance

      • If there is an index (a, b), it is not necessary to create an index (a) separately

      • If there is a joint query of (a, b), is there another query based on a and b?

        • At this time, two indexes must be maintained: (a, b) and (b)
    • 2. consider space

      • Such as (name, age) joint index, the name field is relatively large

        • It is recommended to build two indexes: index (name, age) and index (age)

index pushdown

Prior to MySQL 5.6, no optimization

The index condition pushdown introduced by MySQL 5.6 can first judge the fields contained in the index during the index traversal process, directly filter out the records that do not meet the conditions, and reduce the number of table returns

Premise: the joint primary key index (name, age), the query name starts with Zhang, and the age is 10

• No index pushdown process

  • According to the leftmost prefix, when "Zhang" is found in the query, return to the table

• There is an index pushdown process

  • When "Zhang" is found in the query, continue to judge the age, and return to the form only if it meets the requirements

give a chestnut

• Query statement
  select *from geek where c=N order by a limit 1;
  select *from geek where c=N order by b limit 1;
  Why do we need to create three new indexes (a, b), (c, a), (c ,b)? Isn't it enough to create (a, b) and (c)?

For the primary key (a, b)
, sort by a first, then sort by b, and c is unordered

For the index (c, a)
, sort by c first, then sort by a, and record the primary key b at the same time

For the index (c, b)
, sort by c first, then sort by b, and record the primary key a

InnoDB will put the primary key field behind the index definition field, and of
course it will also deduplicate.
Therefore, when the primary key is (a, b),
the index defined as c is actually (c, a, b);
the index defined as (c, a) is actually (c, a, b)

An index defined as (c,b) is actually (c,b,a)

In summary, ca can be removed, and cb needs to be retained