MySQL索引——从入门到出土
文章目录
- MySQL怎么判断要不要加索引？
- 只要创建了索引，就一定会走索引吗？
- 如何判断数据库的索引有没有生效？
- 如何评估一个索引创建的是否合理？
- 索引是越多越好吗？
- 数据库索引失效了怎么办？
- 所有的字段都适合创建索引吗？
索引
概念
索引是一个单独的、存储在磁盘上的数据库结构，包含着对数据表里所有记录的引用指针。
使用索引可以快速找出在某个或多个列中有一特定值的行，所有MySQL列类型都可以被索引，对相关列使用索引是提高查询操作速度的最佳途径。
索引是在存储引擎中实现的，因此，每种存储引擎的索引都不一定完全相同，并且每种存储引擎也不一定支持所有索引类型。MySQL中索引的存储类型有两种，即BTREE和HASH，具体和表的存储引擎相关。
- MyISAM和InnoDB存储引擎只支持BTREE索引；
- MEMORY/HEAP存储引擎可以支持HASH和BTREE索引。
优缺点
优点：
索引的优点主要有以下几条：
- 通过创建唯一索引，可以保证数据库表中每一行数据的唯一性。
- 可以大大加快数据的查询速度，这也是创建索引的主要原因。
- 在实现数据的参考完整性方面，可以加速表和表之间的连接。
- 在使用分组和排序子句进行数据查询时，也可以显著减少查询中分组和排序的时间。
缺点：
增加索引也有许多不利的方面，主要表现在如下几个方面：
- 创建索引和维护索引要耗费时间，并且随着数据量的增加所耗费的时间也会增加。
- 索引需要占磁盘空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果有大量的索引，索引文件可能比数据文件更快达到最大文件尺寸。
- 当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。
索引的种类
参考答案
MySQL的索引可以分为以下几类：
1. 普通索引和唯一索引
普通索引是MySQL中的基本索引类型，允许在定义索引的列中插入重复值和空值。
唯一索引要求索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。
注意：主键索引是一种特殊的唯一索引，不允许有空值。
2. 单列索引和组合索引
单列索引即一个索引只包含单个列，一个表可以有多个单列索引。
组合索引是指在表的多个字段组合上创建的索引，只有在查询条件中使用了这些字段的左边字段时，索引才会被使用。
注意：使用组合索引时遵循最左前缀集合。
3. 全文索引
全文索引类型为FULLTEXT，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。
全文索引可以在CHAR、VARCHAR或者TEXT类型的列上创建。
4. 空间索引
空间索引是对空间数据类型的字段建立的索引，MySQL中的空间数据类型有4种，分别是
GEOMETRY、POINT、LINESTRING和POLYGON。
MySQL使用SPATIAL关键字进行扩展，使得能够用创建正规索引类似的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MyISAM的表中创建。
MySQL索引
如何创建及保存MySQL的索引
MySQL支持多种方法在单个或多个列上创建索引：
在创建表的时候创建索引：
使用CREATE TABLE创建表时，除了可以定义列的数据类型，还可以定义主键约束、外键约束或者唯一性约束，而不论创建哪种约束，在定义约束的同时相当于在指定列上创建了一个索引。
创建表时创建索引的基本语法如下：
CREATE TABLE table_name [col_name data_type] [UNIQUE|FULLTEXT|SPATIAL] [INDEX|KEY] [index_name] (col_name [length]) [ASC|DESC]
其中，UNIQUE、FULLTEXT和SPATIAL为可选参数，分别表示唯一索引、全文索引和空间索引；INDEX与KEY为同义词，两者作用相同，用来指定创建索引。
例如，可以按照如下方式，在id字段上使用UNIQUE关键字创建唯一索引：
CREATE TABLE t1 ( id INT NOT NULL, name CHAR(30) NOT NULL, UNIQUE INDEX UniqIdx(id) );
在已存在的表上创建索引：
在已经存在的表中创建索引，可以使用ALTER TABLE语句或者CREATEINDEX语句。
ALTER TABLE创建索引的基本语法如下：
ALTER TABLE table_name ADD [UNIQUE|FULLTEXT|SPATIAL] [INDEX|KEY] [index_name] (col_name[length],...) [ASC|DESC]
-- 创建book表 CREATE TABLE book ( id INT NOT NULL, name CHAR(30) NOT NULL ); -- 使用alter创建索引 ALTER TABLE book ADD UNIQUE INDEX UniqidIdx (id);
CREATE INDEX创建索引的基本语法如下：
CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name ON table_name (col_name [length],...) [ASC|DESC]
例如，可以按照如下方式，在bookId字段上建立名称为UniqidIdx的唯一索引：
drop TABLE book; -- 创建book表 CREATE TABLE book ( id INT NOT NULL, name CHAR(30) NOT NULL ); -- 使用create创建索引 CREATE UNIQUE INDEX UniqidIdx ON book (id);
这么多数据结构 MySQL 为什么选择 B+tree 作为索引的数据结构？
下面我们来对比一下B+tree 与其他的数据结构：
1、B+Tree vs B Tree
B+Tree 只在叶子节点存储数据，而 B 树 的非叶子节点也要存储数据，所以 B+Tree 的单个节点的数据量更小，在相同的磁盘 I/O 次数下，就能查询更多的节点。
另外，B+Tree 叶子节点采用的是双链表连接，适合 MySQL 中常见的基于范围的顺序查找，而 B 树无法做到这一点。
2、B+Tree vs 二叉树
对于有 N 个叶子节点的 B+Tree，其搜索复杂度为O(logdN)，其中 d 表示节点允许的最大子节点个数为 d 个。
在实际的应用当中， d 值是大于100的，这样就保证了，即使数据达到千万级别时，B+Tree 的高度依然维持在 3~4 层左右，也就是说一次数据查询操作只需要做 3~4 次的磁盘 I/O 操作就能查询到目标数据。
而二叉树的每个父节点的儿子节点个数只能是 2 个，意味着其搜索复杂度为 O(logN)，这已经比 B+Tree 高出不少，因此二叉树检索到目标数据所经历的磁盘 I/O 次数要更多。
3、B+Tree vs Hash
Hash 在做等值查询的时候效率贼快，搜索复杂度为 O(1)。
但是 Hash 表不适合做范围查询，它更适合做等值的查询，这也是 B+Tree 索引要比 Hash 表索引有着更广泛的适用场景的原因。
索引小细节
MySQL怎么判断要不要加索引？
建议按照如下的原则来创建索引：
- 当唯一性是某种数据本身的特征时，指定唯一索引。使用唯一索引需能确保定义的列的数据完整性，以提高查询速度。
- 在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引，如果待排序的列有多个，可以在这些列上建立组合索引。
只要创建了索引，就一定会走索引吗？
答案是：不一定。
比如，在使用组合索引的时候，如果没有遵从“最左前缀”的原则进行搜索，则索引是不起作用的。
举例，假设在id、name、age字段上已经成功建立了一个名为MultiIdx的组合索引。索引行中按id、name、age的顺序存放，索引可以搜索id、（id,name）、（id, name, age）字段组合。如果列不构成索引最左面的前缀，那么MySQL不能使用局部索引，如（age）或者（name,age）组合则不能使用该索引查询。
后面对单独写一篇博客再来讲解，不慌
如何判断数据库的索引有没有生效？
可以使用EXPLAIN语句查看索引是否正在使用。
举例，假设已经创建了book表，并已经在其year_publication字段上建立了普通索引。执行如下语句：
-- 解释查询语句 EXPLAIN SELECT * FROM user WHERE id=3;
例如我们测试一下：
# 创建用户表 DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '用户名称', `birthday` datetime(0) NULL DEFAULT NULL COMMENT '生日', `sex` char(1) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '性别', `address` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '地址', PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 8 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; -- ---------------------------- -- Records of user -- ---------------------------- INSERT INTO `user` VALUES (1, '玉如', '2019-02-27 17:47:08', '男', '北京市西区'); INSERT INTO `user` VALUES (2, '晓兰', '2019-03-02 15:09:37', '男', '北京市东区'); INSERT INTO `user` VALUES (3, '花蝶', '2019-03-04 11:34:34', '女', '北京市青湖区'); INSERT INTO `user` VALUES (4, '兰咯', '2019-03-04 12:04:06', '女', '北京市青谱区'); INSERT INTO `user` VALUES (5, '咕咕', '2019-03-07 17:37:26', '女', '北京市红滩区'); INSERT INTO `user` VALUES (6, '嘻嘻', '2019-03-08 11:44:00', '男', '北京市新区'); INSERT INTO `user` VALUES (7, '萌萌', '2019-04-08 11:44:00', '男', '北京市西区'); -- 创建主键索引 CREATE UNIQUE INDEX UniqidIdx ON user (id); -- 解释查询语句 EXPLAIN SELECT * FROM user WHERE id=3;
查询结果为：
EXPLAIN语句将为我们输出详细的SQL执行信息，其中：
possible_keys行给出了MySQL在搜索数据记录时可选用的各个索引。key行是MySQL实际选用的索引。
如果possible_keys行和key行都包含id字段，则说明在查询时使用了该索引。
如何评估一个索引创建的是否合理？
建议按照如下的原则来设计索引：
- 避免对经常更新的表进行过多的索引，并且索引中的列要尽可能少。应该经常用于查询的字段创建索引，但要避免添加不必要的字段。
- 数据量小的表最好不要使用索引，由于数据较少，查询花费的时间可能比遍历索引的时间还要短，索引可能不会产生优化效果。
- 在条件表达式中经常用到的不同值较多的列上建立索引，在不同值很少的列上不要建立索引。比如在学生表的“性别”字段上只有“男”与“女”两个不同值，因此就无须建立索引，如果建立索引不但不会提高查询效率，反而会严重降低数据更新速度。
- 当唯一性是某种数据本身的特征时，指定唯一索引。使用唯一索引需能确保定义的列的数据完整性，以提高查询速度。
- 在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引，如果待排序的列有多个，可以在这些列上建立组合索引。
索引是越多越好吗？
索引并非越多越好，一个表中如有大量的索引，不仅占用磁盘空间，还会影响INSERT、DELETE、UPDATE等语句的性能，因为在表中的数据更改时，索引也会进行调整和更新。
数据库索引失效了怎么办？
可以采用以下几种方式，来避免索引失效：
- 使用组合索引时，需要遵循“最左前缀”原则；
- 不在索引列上做任何操作，例如计算、函数、类型转换，会导致索引失效而转向全表扫描；
- 尽量使用覆盖索引（即访问索引列的查询），减少 select * 覆盖索引能减少回表次数；
- MySQL在使用不等于（!=或者<>）的时候无法使用索引会导致全表扫描；
- LIKE以通配符开头（%abc）MySQL索引会失效变成全表扫描的操作；
- 字符串不加单引号会导致索引失效（可能发生了索引列的隐式转换）；
- 少用or，用它来连接时可能会索引失效。
所有的字段都适合创建索引吗？
当然不是。
下列几种情况，是不适合创建索引的：
- 频繁更新的字段不适合建立索引；
- where条件中用不到的字段不适合建立索引；
- 数据比较少的表不需要建索引；
- 数据重复且分布比较均匀的的字段不适合建索引，例如性别、真假值；
- 参与列计算的列不适合建索引。
