Article Directory
index structure problem
- When InnoDB builds an index structure to manage data, why can't other data structures work?
Linked list: linear traversal is not suitable for efficiency
Binary search tree: When traversing down from the root node, many nodes may be encountered, which also means multiple IOs; there is also a degradation problem, which may degenerate into a linear structure, and the efficiency is not high at this time
AVL && red-black tree: Although it is balanced or approximately balanced, it is a binary structure after all. Compared with higher-order B+, it means that the tree as a whole is too high. Everyone looks from top to bottom. The lower the layer height, it means that the system Interact with fewer IO Pages on the hard disk. Although you are beautiful, there are better ones.
Hash: The time efficiency is O(1), which is very suitable in theory, and the search efficiency is really fast; in the official index implementation, MySQL supports HASH, but InnoDB and MyISAM do not. Hash follows up its algorithm characteristics , it is decided that although it is sometimes very fast (O(1)), however, in the face of it
范围查找就明显不行, there are other differences, you can understand it yourself.
- B tree: The most worthy comparison is why InnoDB uses B+ tree instead of B tree as the underlying index
B+ tree
Choose B+ tree: non-leaf nodes do not store data, and all data is in leaf nodes, so that one node can store more keys. The tree can be made shorter, so the number of IO operations is less.
The leaf nodes are connected, which is more convenient for range searchB-tree
B tree nodes have both data and Page pointers, and B+, only leaf nodes have data, and other directory pages only have key values and Page pointers.
B+leaf nodes are all connected, while B does not
Clustered and non-clustered indexes
MyISAM storage engine-primary key index
MyISAM engine also uses B+ tree as the index result, and the data field of the leaf node stores the address of the data record.
Among them, the biggest feature of MyISAM is that it separates the index page from the data page, that is, the leaf node has no data, only the address of the corresponding data.
Compared with InnoDB index, InnoDB puts index and data together.MyISAM, an indexing scheme that separates user data from index data, is called
非聚簇索引InnoDB's indexing scheme for user data and index data is called
聚簇索引
- Create InnoDB tables, clustered indexes
mysql> create table test1(
-> id int primary key,
-> name varchar(20) not null
-> )engine=innodb;
Query OK, 0 rows affected (0.21 sec)
View the corresponding files as follows:
- Create myisam table, non-clustered index
mysql> create table test2(
-> id int primary key,
-> name varchar(20) not null
-> )engine=myisam;
Query OK, 0 rows affected (0.02 sec)
Of course, in addition to the primary key index that MySQL will create by default, our users may also create indexes based on other column information. Generally, such indexes can be called auxiliary (ordinary) indexes. For MyISAM, there is no difference between creating an auxiliary (ordinary) index and a primary key index, except that the primary key cannot be repeated, but the non-primary key can be repeated.
The figure below is the index created based on MyISAM's Col2, which is no different from the primary key index
The structure of the index is the B+ structure
InnoDB In addition to the primary key index, the user will also create an auxiliary (ordinary) index. We create the corresponding auxiliary index for Col3 in the above table as shown in the figure below:
It can be seen that the leaf nodes in InnoDB's non-primary key index do not have data, but only the key value of the corresponding record . Therefore, to find the target record through the auxiliary (ordinary) index, two indexes are required: firstly, the auxiliary index is retrieved to obtain the primary key, and then the primary key is used to retrieve the record from the primary index. This process is called back-to-table query .
For this auxiliary (ordinary) index scenario, InnoDB does not attach data to leaf nodes because it is too wasteful of space.
index operation
Create primary key index
The first way: directly specify the primary key
-- 在创建表的时候，直接在字段名后指定 primary key
create table user1(id int primary key, name varchar(30));
This is used directly when creating a table, needless to say
The second way: similar to the first way
-- 在创建表的最后，指定某列或某几列为主键索引
create table user2(id int, name varchar(30), primary key(id));
The third way: add a primary key
create table user3(id int,name varchar(30));
-- 创建表以后添加主键
alter table user3 add primary key(id);
For example, now the table test1 does not have a primary key index, we use alter table table name add primary key(id) to add a primary key index, the result is as follows:
Looking at the index: we can clearly see Key_name: PRIMARY
主键索引的特点:
In a table, there is at most one primary key index. Of course, it can make the primary key
index more efficient (primary key cannot be repeated).
Create a column for the primary key index. Its value cannot be null, and
the column for the primary key index that cannot be repeated is basically an int
unique index creation
The first way: When creating a table, directly specify the unique attribute directly after a column
-- 在表定义时，在某列后直接指定unique唯一属性。
create table user4(id int primary key, name varchar(30) unique);
The second way: it is actually similar to the first way
-- 创建表时，在表的后面指定某列或某几列为unique
create table user5(id int primary key, name varchar(30), unique(name));
The first two are used directly when creating a table.
The third way: add a unique index after the table is created
This one is to add a unique index after the table is created, as follows:
create table user6(id int primary key, name varchar(30)）；
alter table user6 add unique(name);
For example: To add a unique index to table test1, alter table test1 add unique(name):
Normal index creation
The first way: specify a column as an index at the end of the table definition
create table user8(id int primary key,
name varchar(20),
email varchar(30),
index(name)
);
The second way: create a table, and then specify a column as a normal index
alter table test1 add index(name);
The third way:-- Create an index named myindex:
create index myindex on test1(name);
If the index is not needed, it can be deleted naturally: such as alter table test1 drop index myindex;
Full-text index creation
When searching for an article field or a field with a large amount of text, if you want to find some fields in a certain column, it is not just a record, but a full-text index will be used.
MySQL provides a full-text index mechanism, but there is a requirement that the storage engine of the table must be MyISAM , and the default full-text index supports English, not Chinese . If you want to perform full-text search on Chinese, you can use the Chinese version of sphinx (coreseek)
- Preparation
Create a table articles whose engine is MyISAM, in which the title and body are specified as full-text indexes, as follows:
CREATE TABLE articles (
id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
title VARCHAR(200),
body TEXT,
FULLTEXT (title,body)
)engine=MyISAM;
Also insert some data:
INSERT INTO articles (title,body) VALUES
('MySQL Tutorial','DBMS stands for DataBase ...'),
('How To Use MySQL Well','After you went through a ...'),
('Optimizing MySQL','In this tutorial we will show ...'),
('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
('MySQL vs. YourSQL','In the following database comparison ...'),
('MySQL Security','When configured properly, MySQL ...');
- Query whether there is database data
If you use the following query method, although the data is queried, the full-text index is not used:
select * from articles where body like '%database%';
You can use the explain tool to see if the index is used:
explain select * from articles where body like '%database%'\G
- use full text index
select * from articles where match(title,body) against('database');
delete index
First method - drop primary key index :
alter table 表名 drop primary key;
for example:
The second method - delete other indexes : alter table table name drop index index name; the index name is the Key_name field in the show keysfrom table name
For example, delete the unique index name in table test1 as follows: alter table test1 drop index name;
The third method method: drop index index name on table name
For example: delete the index title of the table articles
drop index title on articles;
query index
The first method: show keys from table name
The second method: show index from table name; this is more commonly used:
The third method (the information is relatively brief): desc table name;
Index Creation Principles
Fields that are frequently used as query conditions should be indexed.
Fields that are too unique are not suitable for creating indexes alone. Even if they are frequently used as query conditions,
fields that are updated very frequently are not suitable for indexing. Fields that
do not appear in the where clause should not be indexed.