How many index types does mysql have? What should be paid attention to when using indexes? sql optimization principle

MySQL index types include:
1. Common index
This is the most basic index without any restrictions. There are the following creation methods:
1. The index creation
code is as follows:

CREATE INDEX indexName ON mytable(username(length));
if it is CHAR or VARCHAR type, the length can be less than the actual length of the field; if it is BLOB and TEXT type, length must be specified , the same below.

2. Modify the table structure

code as follows:
ALTER mytable ADD INDEX [indexName] ON (username(length)) -- Specify it directly when creating a table.
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) );

-- syntax to drop an index:
DROP INDEX [indexName] ON mytable;

Second, the unique index
is the same as The previous ordinary index is similar, 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: 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))
-- Specify
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) ) directly when creating the table ;

Third, the primary key index
It is a special unique index that does not allow null values. Generally, the primary key index is created at the same time when the table is built: 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 composite index
In order to visually compare the single-column index and the composite index, add multiple fields to the table: 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.
Two: Precautions for
using indexes When using indexes, there are some skills and precautions as follows:
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 a short index to index
the string column, and if possible should specify a prefix length . 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 use only one index, so if the index has been used in the where clause, the column 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. The like statement operation
is generally discouraged from using the like operation. 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 perform operations on columns

select * from users where YEAR(adddate)<2007;
will perform operations on each row, which will cause the index to fail and perform a full table scan, so we can change it to:

select * from users where adddate<'2007-01-01';

6. Do not use NOT IN and <> operations. Three: The common simplification rules for

SQL optimization principles are as follows:

1. Do not have more than 5 table joins (JOIN)
2. Consider using temporary tables or table variables to store intermediate results.
3. Less use of subqueries
4. View nesting should not be too deep. Generally, it is advisable not to nest more than 2 views.
5. The more tables that are connected, the greater the compilation time and connection overhead, and the less controllable the performance.
6. It is best to split the connection into smaller parts and execute them one by one.
7. Prioritize joins that significantly reduce results.
8. The benefit of splitting is not only to reduce SQL Server optimization time, but also to allow SQL statements to execute in a way and order that you can predict.

If you must join many tables to get the data, it probably means a design flaw.