Summary of MySQL index types and usage tips and precautions

In database tables, indexing fields can greatly improve query speed. Suppose we create a mytable table:

 

Copy the code The code is as follows:
CREATE TABLE mytable(   ID INT NOT NULL,    username VARCHAR(16) NOT NULL  );

 

We randomly inserted 10,000 records into it, one of which was: 5555, admin.

When looking for a record with username="admin" SELECT * FROM mytable WHERE username='admin';, if an index has been established on the username, MySQL can accurately find the record without any scanning. Instead, MySQL scans all records, i.e. 10000 records to query.

The index is divided into single-column index and composite index. Single-column index, that is, an index contains only a single column, a table can have multiple single-column indexes, but this is not a composite index. Composite index, that is, an index contains multiple columns.

MySQL index types include:

1. Common index

This is the most basic index, it has no restrictions. It can be created in the following ways:

1. Create an index

 

Copy the code The code is as follows:
CREATE INDEX indexName ON mytable(username(length));

 

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

2. Modify the table structure

Copy the code The code is as follows:

ALTER mytable ADD INDEX [indexName] ON (username(length)) -- specify it directly when creating the table

 

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

-- Syntax to delete an index:

DROP INDEX [indexName] ON mytable;

 

Second, the unique index

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

 

Copy the code The code is as follows:
CREATE UNIQUE INDEX indexName ON mytable(username(length))
-- modify the table structure
ALTER mytable ADD UNIQUE [indexName] ON (username(length))
-- directly specify
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR when creating a table (16) NOT NULL, UNIQUE [indexName] (username(length)) );

 

Third, the primary key index

It is a special unique index that does not allow nulls. Generally, the primary key index is created at the same time when the table is built:

 

Copy the code The code is as follows:
CREATE TABLE mytable(   ID INT NOT NULL,    username VARCHAR(16) NOT NULL,   PRIMARY KEY(ID)   );

 

Of course, you can also use the ALTER command. Remember: a table can only have one primary key.

Fourth, the combined index

To visually compare single-column and composite indexes, add multiple fields to the table:

Copy the code The code is as follows:
CREATE TABLE mytable(   ID INT NOT NULL,    username VARCHAR(16) NOT NULL,   city VARCHAR(50) NOT NULL,   age INT NOT NULL  ); 

 

In order to further squeeze the efficiency of MySQL, it is necessary to consider building a composite index. It is to build name, city, age into an index:

 

Copy the code The code is as follows:
ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);[code]
When creating a table, the username length is 16, and 10 is used here. This is because in general, the length of the name will not exceed 10, which will speed up the index query speed, reduce the size of the index file, and improve the update speed of INSERT.

 

If a single-column index is established on username, city, and age respectively, and the table has three single-column indexes, the efficiency of the query will be very different from the above combined index, which is far lower than our combined index. Although there are three indexes at this point, MySQL can only use the single-column index that it believes appears to be the most efficient.

Establishing such a composite index is actually equivalent to establishing the following three sets of composite indexes:

username,city,age username,city username Why is there no combined index like city and age? This is because of the "leftmost prefix" result of the MySQL composite index. The simple understanding is to only start the combination from the leftmost. This composite index is not used in any query that contains these three columns. The following SQL will use this composite index:
[code]
SELECT * FROM mytable WHREE username="admin" AND city="Zhengzhou" SELECT * FROM mytable WHREE username="admin"

 

The following will not be used:

Copy the code The code is as follows:

SELECT * FROM mytable WHREE age=20 AND city="郑州"  SELECT * FROM mytable WHREE city="郑州"

 

Fifth, the timing of indexing

So far we have learned to build indexes, so under what circumstances do we need to build indexes? In general, the columns appearing in WHERE and JOIN need to be indexed, but this is not entirely the case, because MySQL only works on <, <=, =, >, >=, BETWEEN, IN, and sometimes LIKE Use index. E.g:

 

Copy the code The code is as follows:
SELECT t.Name  FROM mytable t LEFT JOIN mytable m    ON t.Name=m.username WHERE m.age=20 AND m.city='郑州'

 

At this time, it is necessary to build an index on city and age. Since the userame of the mytable table also appears in the JOIN clause, it is also necessary to build an index on it.

Just mentioned that only some LIKEs need to be indexed. Because MySQL will not use the index when querying with wildcard characters % and _. For example, the following sentence would use an index:

Copy the code The code is as follows:

SELECT * FROM mytable WHERE username like'admin%'


The following sentence will not be used:

Copy the code The code is as follows:
SELECT * FROM mytable WHEREt Name like'%admin'

 

Therefore, you should pay attention to the above differences when using LIKE.

Sixth, the inadequacy of the index

The above are all about the benefits of using indexes, but excessive use of indexes will lead to abuse. So indexing also has its drawbacks:

1. 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.

2. Create an index file that will occupy disk space. In general, this problem is not serious, but if you create multiple composite indexes on a large table, the index file will swell very quickly.

Indexes are only one factor to improve efficiency. If your MySQL table has a large amount of data, you need to spend time researching to establish the best index, or optimize the query statement.

7. Precautions for using indexes

Here are some tips and considerations when working with indexes:

1. The index will not contain columns with NULL values

As long as the column contains NULL values, it will not be included in the index. As long as there is one column in the composite index that contains NULL values, this column is invalid for this composite index. So we don't let the default value of the field be NULL when designing the database.

2. Use short indexes

Index the list, specifying a prefix length if possible. For example, if you have a CHAR(255) column, don't index the entire column if most of the values ​​are unique within the first 10 or 20 characters. Short indexes can not only improve query speed but also save disk space and I/O operations.

3. Index column sorting

MySQL queries only use one index, so if an index is already used in the where clause, the columns in the order by will not use the index. Therefore, do not use the sorting operation if the default sorting of the database can meet the requirements; try not to include sorting of multiple columns, and create composite indexes for these columns if necessary.

4.like statement operation

In general, the use of the like operation is discouraged. If it must be used, how to use it is also a problem. like "%aaa%" will not use the index while like "aaa%" will use the index.

5. Do not operate on columns

Copy the code The code is as follows:

select * from users where YEAR(adddate)<2007;

 

will do the operation on each row, which will cause the index to fail and a full table scan, so we can change it to:

 

Copy the code The code is as follows:
select * from users where adddate<‘2007-01-01';

 

6. Do not use NOT IN and <> operations

Above, the MySQL index types are introduced. I hope to be helpful.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326119184&siteId=291194637