适合构建索引的几种情况：

引言

我们知道正确的建立索引可以加快数据库的查询，但是如果索引建立不当，或者随意的建立过多索引不仅不会提升数据库的效率，反而在进行数据更新操作的时候需要耗费系统资源对索引进行维护，同时占用大量的存储空间来对索引进行存储，本文主要讲述在哪些情况下适合建立索引

结论：

  1. 在where后面的过滤字段上建立索引(select/update/delete后面的where都是适用的)，使用索引加快过滤效率，不用进行全表扫描
  2. 在具有唯一要求的字段上添加唯一索引，加快查询效率，查到即可直接返回
  3. group by或者order by后面的字段添加索引，由于索引是排好序的，所以建立索引就等同于在查询之前已经是排好序了（这里需要注意建立的联合索引建立中字段的顺序，可以结合具体案例场景7进行学习）
  4. 在DISTINCT（去重字段）后面的字段添加索引，由于建立了索引，那么相同的数据就是挨在一起的，所以就可以进行快速的去重操作，否则可能就需要将相同的数据找出来在进行去重操作
  5. 在多表连接join的时候在连接的字段上建立索引（小表驱动大表）
  6. 取字符串一定前缀建立索引（不是用整个字符串作为索引，否则将会占用太大的空间）
  7. 在频繁使用的列上建立索引（可以建立联合索引，同时最频繁使用的字段应该在联合索引的最左侧，最左侧原则）
  8. 在区分度高的列上建立索引（主键的区分度最高，因为所有的键都是唯一的）

建立索引的场景：

场景一：在where字段后面的字段建立索引
-- 描述：当where中有多个条件需要进行匹配的时候，那么可以创建联合索引，这样所有的条件都可以使用索引，大大提高了检索的效率

select * from student_info where student_id = 1;
-- 当然数据量比较大的时候给where后面的字段添加索引
create index student_id_index on student_info (student_id)

未添加索引前，耗费0.383秒，基本遍历整个表

mysql什么时候用numeric mysql什么时候会用到索引_字段

添加索引后，耗费0.001秒，使用了索引（但是创建索引的时候会耗费一定时间）

mysql什么时候用numeric mysql什么时候会用到索引_mysql_02

在频繁的查询的业务中可以对where筛选的字段建立索引，如果where筛选的字段有多个还可以建立联合索引

场景二：在具有唯一性约束的字段上建立唯一索引（查找到目标即可返回不用继续查找）
select * from student_info where id = 1001;
-- 因为学号是唯一的，所以可以在学号这个字段上添加唯一所用
create index id_unique on student_info(id);

具有唯一性约束的字段上就可以建立唯一索引，虽然建立了唯一索引对insert操作有一定的影响(需要判断新增的数据是否已经在表中)，但是建立唯一索引对于查询的效率是显著提升的，例如上面的例子，因为建立了唯一索引，一旦查找到id为1001的学生信息之后就不需要判断数据库中是否还有id等于1001的学生（只有唯一一份），直接返回信息即可，如果没有建立索引，那么就需要全表扫描

场景三：经常group by和order by的字段上建立索引（因为索引本身就是排好序的，相当于查询之前就已经进行了排序）
select * from student_info order by name;
-- 这里就可以给name字段进行索引的添加
select * from student_info group by class_id;
-- 这里就可以给class_id字段添加索引

建立索引前，耗时0.501秒，使用的是所有数据在内存中排序

mysql什么时候用numeric mysql什么时候会用到索引_字段_03

建立索引后，耗时0.01秒

mysql什么时候用numeric mysql什么时候会用到索引_mysql什么时候用numeric_04

场景四：在DISTINCT后面的字段添加索引（索引已经将相同的字段排好序，去重效率更高）
select distinct(student_id) from student_info;
-- 这里就可以根据student_id字段建立索引
create index student_id_index on student_info;

建立了索引，那么默认就是按照索引字段的升序排列的，那么相同值的字段也就排列在一起了，那么去重也就变得简单、高效

场景五：在join多表连接大表中的连接字段建立索引
SELECT s.course_id,NAME,s.student_id,c.course_name
FROM student_info s JOIN course c
ON s.`course_id` = c.`course_id`
WHERE NAME = 'xiaoyuanhao';
-- 根据大表驱动小表的原则需要在student_info表的course_id字段上建立索引

没有建立索引之前，耗时0.697s，没有使索引

mysql什么时候用numeric mysql什么时候会用到索引_sql_05


建立索引后，使用了索引，耗时0.003s

mysql什么时候用numeric mysql什么时候会用到索引_mysql_06

小表驱动大表：
通过对小表进行逐一遍历，同时在大表中的连接字段建立索引即可加快查询，本案例中，每次取出课程表中course_id和学生表中学生的course_id进行连接操作，在学生表中对course_id建立索引即可

场景六：使用字符串的前缀建立索引
create table shop(address varchar(120) not null);

alter table shop add index(address(12));

--这里只是对表中的address的前12个字符建立了索引，而不是整个字符串建立索引

前缀建立索引的原因：

  • 由于有些字符串很长，如果为整个字符串建立索引，那么索引将占用很大的空间
  • 由于需要存储整个字符串，那么数据项就会很大，那么索引树的深度就会加深，检索速度下降
  • 虽然可能出现在索引中两个字符串相同，但是再根据主键进行回表操作效率依然比较高

如何确定前缀索引中前缀的长度呢？（也就是如果前缀的长度太短，那么索引的区分度就很低，从多个字符串截取的前缀数据可能都是一样的，但是如果前缀索引的前缀过长，那么前缀索引的优点就消失了）

  • 引入了区别度的概念，select count(distinct left(索引字段,前缀索引长度) / count(*) from xxx)，该值越接近1，那么区分度就越明显，那么该索引长度就是所求的前缀索引长度
场景七：在频繁使用的列上建立索引或联合索引（频繁使用的字段应该在索引的左侧）
select * from xiaoyuanhao where age = 18;
select * from xiaoyuanhao where age = 19 and sex = 'man';
select * from xiaoyuanhao where age = 10 and sex = 'man' and password = '123456';
-- 在这里实际上就可以建立age,sex,password的联合索引，只需要建立一个索引，这三个查询都是可以使用的
create index age_sex_password_index on xiaoyuanhao(age,sex,password);

select * from student_info group by class_id order by name;
-- 在这里可以建立class_id和name的联合索引，但是一定要注意索引的顺序，一定是要class_id在前，name在后，因为在select语句中执行的顺序是先group by 之后才是 order by 索引如果索引的字段顺序是相反的，那么就无法使用索引
create index class_id_name_index on student(class_id,name);

索引建立需要符合顺序的原因：

  • 索引字段的顺序如果是错误的，那么索引就会失效，因为索引实际上是排好序的，如果索引建立的时候是现根据name排好序之后在根据class_id进行排序，那么在面对需要先根据class_id排序再根据name排序的业务就无法进行使用

补充：

  • 在select * from xxx where age = 19 and sex = ‘man’ and password = '123456’这里索引建立的顺序不一定是(age,sex,password)因为在实际执行的过程中，优化器会优化执行步骤会按照索引的顺序进行查询，但是group by 和 order by的执行顺序是无法改变的，索引必须严格的按照顺序建立索引，否则索引失效

小结

  • 以上是适合建立索引的几种情况，但是实际上是否会使用索引，还是由优化起决定的，优化器会根据具体的查询以及数据量进行分析决定的
  • 当建立了索引但是却没有使用的时候有可能是数据索引失效或者经过优化器分析没有必要使用索引
  • 建立了索引也是存在失效的可能，下面的文章关于索引失效的案例，可以一起学习讨论：索引优化：索引失效以及不适合建立索引的场景