Mysql index classification and its usage examples

Mysql index classification

MySQL index
The establishment of MySQL index is very important for the efficient operation of MySQL, and the index can greatly improve the retrieval speed of MySQL. For example, if a properly designed and indexed MySQL is a Lamborghini, then a MySQL without an index is a rickshaw.
Take the catalog page (index) of the Chinese dictionary as an example, we can quickly find the desired word in the catalog (index) sorted by pinyin, strokes, radicals, etc. Indexes are divided into single-column indexes and composite indexes. Single-column index, that is, an index contains only a single column, and a table can have multiple single-column indexes, but this is not a composite index. Composite index, that is, an index contains multiple columns. When creating an index, you need to ensure that the index is applied to the condition of the SQL query statement (generally as the condition of the WHERE clause). In fact, an index is also a table, which stores the primary key and index fields, and points to the records of the entity table. The above are all about the benefits of using indexes, but excessive use of indexes will cause abuse. Therefore, the index will also have its disadvantages: although the index greatly improves the query speed, it will reduce the speed of updating the table, such as INSERT, UPDATE and DELETE on the table. Because when updating the table, MySQL not only saves the data, but also saves the index file. Indexing an index file that takes up disk space.

single column index

A single-column index can also be called an ordinary index. An index contains only one column, and there can be multiple single-column indexes in a table.

Several ways to create a single-column index:

• Created externally

CREATE INDEX indexName ON table_name (column_name)

• Modify table structure (add index)

ALTER table tableName ADD INDEX indexName(columnName)

• Specify directly when creating the table

For CHAR and VARCHAR types, length can be less than the actual length of the field; for BLOB and TEXT types, length must be specified.

CREATE TABLE mytable(  
 
ID INT NOT NULL,   
 
username VARCHAR(16) NOT NULL,  
 
INDEX [indexName] (username(length))  
 
); 

unique index

It is similar to the previous ordinary index, the difference is that the value of the index column must be unique, but null values ​​are allowed. If it is a composite index, the combination of column values ​​must be unique. It can be created in the following ways:

Several ways to create a unique index:

• Created externally

CREATE UNIQUE INDEX indexName ON mytable(username(length)) 

• Modify table structure (add index)

ALTER table mytable ADD UNIQUE [indexName] (username(length))

• Specify directly when creating the table

CREATE TABLE mytable(  
 
ID INT NOT NULL,   
 
username VARCHAR(16) NOT NULL,  
 
UNIQUE [indexName] (username(length))  
 
); 

Joint index (composite index)

The composite index is the most powerful one in the index, the index can cover multiple data columns at the same time,

How to create a joint index (composite index):

• Created externally

CREATE INDEX indexName ON mytable(c1,c2,c3...)

Mysql index type

INDEX | NORMAL normal index

Works in most cases, allowing the same indexed content to appear.

UNIQUE unique index

The same value cannot appear, and NULL values ​​are allowed. If the field information is guaranteed not to be repeated, for example, when the ID number is used as an index, it can be set to UNIQUE

Constraints uniquely identify each record in the database table, that is, each record cannot be unique in a single table (for example, the ID card is unique), UNIQUE (requiring the column to be unique) and Primary Key (primary key = unique + not null Column unique) constraints provide a guarantee of uniqueness in a column or column set. Primary Key is an automatically defined UNIQUE constraint, but each table can have multiple UNIQUE constraints, but there can only be one Primary Key constraint.

PRIMARY KEY primary key index

The same value is not allowed, and it cannot be NULL. A table can only have one PRIMARY KEY index.

FULLTEXT full-text index

Full-text index can target a single city in the value, such as a certain word in an article, but it is useless, because only myisam and English support, and the efficiency is not flattering, but you can use coreseek and Third-party applications such as xunsearch can fulfill this requirement.

SPATIAL spatial index

Spatial index is an index established on fields of spatial data type. There are four spatial data types in MYSQL, namely GEOMETRY, POINT, LINESTRING, and POLYGON. MYSQL is extended with the SPATIAL keyword to enable the creation of spatial indexes using the syntax for creating regular index types. To create a column of a spatial index, it must be declared as NOT NULL. A spatial index can only be created on a table whose storage engine is MYISAM.

Mysql index method

BTREE

B-tree (can be a multi-fork tree), the default method used by mysql, is a field indexed by the BTREE algorithm. For example, by scanning 20 rows, you can get the result of scanning 2^20 rows before using BTREE.

HASH

Hash algorithm, the hash algorithm establishes the characteristic value, and then quickly finds it according to the characteristic value. This method does not support range queries very well

Due to the particularity of the hash index structure, its retrieval efficiency is very high. The index retrieval can be located at one time. Unlike the BTREE index, which needs to go from the root node to the branch node, and finally access the page node for multiple IO accesses, so the query of the Hash index Efficiency is much higher than BTREE index.
Many people may have doubts again. Since the efficiency of Hash index is much higher than that of BTREE, why don't everyone use Hash index instead of BTREE index? Everything has two sides, and the Hash index is the same. Although the Hash index is highly efficient, the Hash index itself has many limitations and disadvantages due to its particularity, mainly as follows.

(1) Hash indexes can only satisfy "=", "IN" and "<=>" queries, and range queries cannot be used.

Since the Hash index compares the Hash value after the Hash operation, it can only be used for equivalent filtering and cannot be used for range-based filtering, because the size relationship of the Hash value processed by the corresponding Hash algorithm cannot be determined. It is guaranteed to be exactly the same as before the Hash operation.

(2) Hash indexes cannot be used to avoid data sorting operations.

Since the Hash index stores the Hash value after Hash calculation, and the size relationship of the Hash value is not necessarily exactly the same as the key value before the Hash operation, so the database cannot use the index data to avoid any sorting operation;

(3) The Hash index cannot be queried using some index keys.

For a composite index, when calculating the Hash value of the Hash index, the composite index keys are merged and then the Hash value is calculated together, rather than the Hash value is calculated separately. also cannot be exploited.

(4) Hash indexes cannot avoid table scans at any time.

As we have known before, the Hash index is to store the Hash value of the Hash operation result and the corresponding row pointer information in a Hash table after the index key is subjected to the Hash operation. The number of data records of a Hash key value cannot be directly queried from the Hash index. It is still necessary to compare the actual data in the access table and obtain the corresponding results.

(5) The performance of the Hash index is not necessarily higher than that of the B-Tree index when a large number of Hash values ​​are equal.

For index keys with relatively low selectivity, if a Hash index is created, there will be a large number of record pointer information associated with the same Hash value. In this way, it will be very troublesome to locate a certain record, and it will waste multiple accesses to table data, resulting in low overall performance.

In the actual operation process, which fields in the table should be selected as the index?
In order to make the use of the index more efficient, when creating the index, you must consider which fields to create the index on and what type of index to create. There are 7 principles: 1
. Select a unique index
2 . Build indexes for the fields that often need sorting, grouping and joint operations3
. 4. Create indexes for the fields that are often used as query conditions
. Limit the number of indexes
5. Try to use the index with less data volume
6. Try to use prefixes to index
7．Delete indexes that are no longer used or rarely used
8. Do not create indexes for fields that are frequently updated and modified (for mysql, because the index must be re-established and sorted when the field is changed, and Oracle seems to have such a mechanism when the field value changes, It does not immediately build and sort indexes, but balances the index according to the number of changes and the time period)
9. It is not recommended to build multiple indexes on the same column

Mysql index use example

All the following index operations will be demonstrated around this table. Before demonstrating the index, let’s introduce explain first. For more information, see Cainiao Index Optimization

• The function of mysql explain is:

Simulate how the Mysql optimizer executes SQL query statements, so as to know how Mysql processes your SQL statements. Analyze the performance bottleneck of your query statement or table structure. (Here is just a brief introduction, how to use it, just add explain before the select statement)

Example of using a single-column index

1. Create a normal index for the site_number field of the monitor_concentration table

-- 创建索引  siteNumber：索引名称唯一，monitor_concentration：表名，site_number：字段名
CREATE INDEX siteNumber ON monitor_concentration(site_number)

Successfully created as follows:

Use explainthe query optimization test to see the difference between using an index and not using an index

select site_number from monitor_concentration where site_number = 2036

• Before using the index:

It can be seen that when no index is used, the query time is 2.132 seconds

• After using the index:

You can use the index to execute this statement here, and the query time is 0.598 seconds (the gap is obvious)

• The created index is not used as a condition

It can be seen that the return value uses the index, which is equally effective when querying the column, and the efficiency is higher than no index

• Use indexes with other fields

result one

result two

result three

Summarize the use of single-column indexes: It can be seen that we have created an index for the field siteNumber, and when using it as a condition and return statement (as a where condition, it also has a return value. If it is not used as a where condition, the return value can have it ), it can quickly help us achieve the effect when querying, but when used together with other fields. It doesn't work. So we can use a single-column index when querying a single column. If you want to combine multiple fields, I will use a composite index to achieve this (this method is more common than a single column)

Composite index use example

1. Create a composite index for the site_number and date_time fields of the monitor_concentration table

-- 创建复合索引
CREATE INDEX idx_c1_c2 ON monitor_concentration(date_time,site_number)

Successfully created as follows:

• use

result one

result two

result three

result four

result five

result six

Summarize the use of composite index: from the use of several results, the composite index has achieved a single-column usage. In the single-column index, we propose the effect we want to achieve, and it is successfully realized in the composite index. Composite indexes are more flexible. We can build composite indexes according to actual needs. Here is an example.

1. Create a composite index for state and date_time

CREATE INDEX idx_st_dt ON monitor_concentration(state,date_time)

• use

result one

result two

I won’t show too many results here. I have demonstrated using the composite index page before (note the previous results five and six, I will make a little change here), and I will demonstrate such an effect

Requirements, query the latest time of monitor_concentration table state=3

select max(date_time) date_time from monitor_concentration where state = 3

After creating the index, why is the query still so slow? The query time is 8.441 seconds

Did you see that we have created a composite index for state and date_time, but it doesn't take effect here!
Because columns using aggregate functions cannot use indexes (but I just want to use indexes...it can be achieved)

Delete the composite index just created and re-create the composite index. The difference between this and the one created above is that state and date_time have exchanged positions

CREATE INDEX idx_st_dt ON monitor_concentration(date_time,state)

• reuse

select max(date_time) date_time from monitor_concentration where state = 3

It can be seen that there is an obvious gap compared to just now, and the query time is 1.819

As you can see, the composite index we created this time is valid

Summary of the order of creating composite index fields: You can see from Liezi that if we are using a special statement and want to make it effective, we need to pay attention to the order of the composite index fields. From here, the column used as the condition should be placed after the column used in the return