Database index knowledge

index

1. Create an index

The CREATE INDEX method is used when creating a table

普通的索引的创建:

CREATE INDEX (自定义)索引名 ON 数据表(字段);

复合索引的创建:

CREATE INDEX (自定义)索引名 ON 数据表(字段,字段....);

ALTER TABLE mode, used to add indexes after the table is built

//普通索引
alter table (表名) add index index_name (字段,字段....) ;
//唯一索引
alter table (表名) add unique (字段,字段....) ;
//主键索引
alter table (表名) add primary key (字段,字段....) ;
//全文索引
ALTER TABLE (表名) ADD FULLTEXT (字段,字段....) ;
//主键索引
ALTER TABLE (表名) ADD INDEX index_name (字段,字段....) ;

2Check if there is an index

Use the EXPLAIN command before the query conditions to view the SQL execution plan. If it is NULL, it means that there is no index.

3. What are the reasons for the slow execution of a SQL statement?

①It is normal in most cases, and occasionally slow

​ 1. The database is flushing dirty pages. For example, the redo log is full and needs to be synchronized to disk.

​ 2. When executing, encounter locks, such as table locks and row locks.

②This SQL statement has been executed very slowly (the index is invalid, or there is no index, the database chooses not to use the index)

  1. Like starts with %, the index is invalid; when the like prefix does not have% and the suffix has %, the index is valid.
  2. The index is not used before and after the or statement. When only one of the query fields on the left and right of or is an index, the index is invalid, and it will take effect only when the query fields on the left and right of or are indexes.
  3. Composite index, instead of using the first column index, the index becomes invalid.
  4. The data type is implicitly converted. If varchar does not add single quotation marks, it may be automatically converted to int type, invalidating the index and generating a full table scan.
  5. Use not, <>, != on the index field. The inequality operator will never use the index, so its processing will only produce a full table scan. Optimization method: Change key<>0 to key>0 or key<0.
  6. Perform calculation operations on index fields and use functions on fields (that is, operations are done on the left). (The index is emp(ename,empno,sal)).
  7. When the full table scan speed is faster than the index speed, mysql will use the full table scan, and the index becomes invalid at this time. (There is a difference between a primary key index and a non-primary key index. The value stored in the primary key index is the data of the entire row of fields , while the value stored in the non-primary key index is not the data of the entire row of fields, and the value of the primary key field is stored .

That is to say, if we take the index of the field that is not the primary key index, we will finally query the value of the corresponding primary key, and then take the primary key index according to the value of the primary key, and query the entire row of data to return. So if you want to query n rows for full table query, the index is 2n. If n is very large, at this time 2n >>n, the database will give up the index and go for full table query)

4. Clustered index

The so-called clustered index means that the data field stores data, and the primary key index belongs to the clustered index.

5. Non-clustered index

A non-clustered index is a pointer to the primary key or data stored in data, and a secondary index is a non-clustered index.

6. Index Coverage

If the field we want to query happens to be indexed, then there is no need to "back to the table" to check it again based on the primary key, and return the value directly

For example: select name from table_a where name='zrx';;At this time, we happen to have an index for the name field, we can get the value of name (because the key of the index is the name), will the system still go according to the primary key Go back to the table and check it again? The answer is definitely no.

Similarly,

For example: select id from table_a where id='10086'; this query will also have index coverage, because the key of the primary key index is also the id, the database will not go back to the table to query again.

This coverage index is a bit weird, so check it again based on a value you already know. But I guess it still works, it should be in the case of right fuzzy query.

7. Which fields are suitable as indexes

1. Frequent queries and infrequent revisions

2. Often used as a conditional query

8.B+ tree

If you don't want to understand too thoroughly, but you want to understand quickly. We might as well think like this. From the name, we can know that this structure is a tree. If we learn the backend, we know that the data stored in the tree is sorted. Therefore, it is not difficult for us to draw conclusions. The keys of the tree are ordered and there is already an interval, the lower the interval, the smaller, and finally the required data is located.

Guess you like

Origin blog.csdn.net/weixin_43957211/article/details/110441628