学会MySQL索引

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介:

就一起来聊一聊MySQL索引。

什么是索引?

百度百科是这样描述的:

索引是为来加速对表中数据行中的检索而创建的一种分散的数据结果,时针对表而建立的,它是由数据页面以外的索引页面组成,每个索引页中的行都含有逻辑指针,以便加速检索物理数据

其实,索引的概念大家都很清楚,也知道索引能够提升查询效率,但大部分童鞋在怎么建索引,建在哪些字段上有以下常见误解:

  • 新建表时不需要建索引,后续才添加索引

  • where条件后的字段均建索引

  • 简单SQL不需要索引,联合查询才需要索引

  • 联合索引的顺序是where条件后字段的先后顺序

  • 对于区分度小的字段上也新建索引,如状态,性别等字段等。

索引区分度

在说上述问题之前,我们先来看看另一个概念,就是区分度。

区分度: 指字段在数据库中的不重复比

区分度在新建索引时有着非常重要的参考价值,在MySQL中,区分度的计算规则如下:

字段去重后的总数与全表总记录数的商。

例如:

select count(distinct(name))/count(*) from t_base_user;

结果如下:

count(distinct(name))/count(*)
1.0000

其中区分度最大值为1.000,最小为0.0000,区分度的值越大,也就是数据不重复率越大,新建索引效果也越好,在主键以及唯一键上面的区分度是最高的,为1.0000。在状态,性别等字段上面的区分度值是最小的。 (这个就要看数据量了,如果只有几条数据,这时区分度还挺高的,如果数据量多,区分度基本为0.0000。也就是在这些字段上添加索引后,效果也不佳的原因。)

值得注意的是:    如果表中没有任何记录时,计算区分度的结果是为空值,其他情况下,区分度值均分布在0.0000-1.0000之间。

如何建索引

   (一)  : 区分度
个人强烈建议, 建索引时,一定要先计算该字段的区分度,原因如下:

1. 单列索引
可以查看该字段的区分度,根据区分度的大小,也能大概知道在该字段上的新建索引是否有效,以及效果如何。区分度越大,索引效果越明显。

2.多列索引(联合索引)
多列索引中其实还有一个字段的先后顺序问题,一般是将区分度较高的放在前面,这样联合索引才更有效,例如:

select * from t_base_user where name="" and status=1;

像上述语句,如果建联合索引的话,就应该是:

alter table t_base_user add index idx_name_status(name,status);

而不是:

alter table t_base_user add index idx_status_name(status,name);

(二) 最左前缀匹配原则
  MySQL会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,比如

select * from t_base_user where type="10" and created_at<"2017-11-03" and status=1, (该语句仅作为演示)

在上述语句中,status就不会走索引,因为遇到<时,MySQL已经停止匹配,此时走的索引为:(type,created_at),其先后顺序是可以调整的,而走不到status索引,此时需要修改语句为:

select * from t_base_user where type=10 and status=1 and created_at<"2017-11-03"

即可走status索引。

(三) 函数运算
  不要在索引列上,进行函数运算,否则索引会失效。因为b+树中存的都是数据表中的字段值,但进行检索时,需要把所有元素都应用函数才能比较,显然成本太大。

(四) 扩展优先
  扩展优先,不要新建索引,尽量在已有索引中修改。如下:

select * from t_base_user where name="andyqian" and email="andytohome"

在表t_base_user表中已经存在idx_name索引,如果需要加入idx_name_email的索引,应该是修改idx_name索引,而不是新建一个索引。

误解纠正

  上面说了,如何新建索引,现在我们就可以来回答,在第一步中存在的误解了。

误解一:   新建表时不需要建立索引,后续才加索引

答: 一个好的数据表设计,在一开始就要考虑索引的创建,而不是等到后续出问题了,影响业务使用了,才新建索引来救场,而且后续创建索引的成本也相对高很多。(这就是给生产事故留下生根发芽的机会呀)

误解二:   where条件后的字段均建索引

答: 这个误解比较常见,但where条件后的字段不需要全部建立索引,过多的索引,也会导致索引文件剧增,也还达不到期望中的效果。详细请参考上述新建索引的小节。

误解三:   简单SQL不需要建立索引,联合查询采建立索引

答: 这个误解就得好好说说了,现在互联网公司特别是B/S架构下,业务逻辑均剥离在代码逻辑层,到最后SQL层面,其实都是一些简单的SQL,只有些许连接查询,更多的还是单表操作,(C/S架构中有很多在SQL层面的写逻辑的),你说这些语句简不简单。

误解四:    联合索引的顺序是where条件后字段的先后顺序

答: 我们刚才说过,联合索引的顺序,是根据最左前缀原则,以及区分度来区分的,和where条件后字段的先后顺序无关。

误解五: 对于区分度较小的字段新建索引

答: 在区分度较小的字段上新建索引,基本无效,还会增加大量的索引文件,你说是不是得不偿失。

索引重不重要?

  上面介绍了MySQL索引的概念,新建索引时的一些技巧。这么理论的东西,对于平时没有使用或使用比较少的童鞋,此时对索引的重要性可能还没那么直观,那么,我就来说说我在索引上吃过的亏,踩过的坑!同时也是未建索引常见问题!

0. 导致慢查询
这个问题可是未建索引的常客哦,(这里也还有很多细节呢,如: 隐式类型转换等等)

1. 导致服务超时

场景 :
  在某次上线时,作为服务提供者,提供服务给业务方使用。一开始以为就提供一个简单的服务,也已经测试完成,心里还在窃喜,今天总算可以早早回家了!


描述 :
  实际一上线,在生产环境中导致业务方请求调用时,而且每次请求均超时,数据也已落地,此时只能review代码,最后发现生产中有个慢查询导致,活活的花费了10多秒,这个语句有多简单呢,你绝对想不到,其实就是一个单表的where条件查询语句。你说这种原因导致服务不可用,你说冤不冤,气不气!(这也是我为什么说,一个好的数据表设计,从一开始就要考虑新建索引了)。

2. 数据库服务器CPU 100%

在查询频率比较高的SQL上,如果由于未建索引,导致慢查询的话,那可是会导致数据库服务器CPU 100%,影响可是整个系统哦。

小结
上面说了好几类,由于没建立索引而导致的问题,轻则导致慢查询,影响系统效率,重则,导致CPU 100%,影响整个系统的使用,看到这里,你说索引重不重要?

最后

上面简单说了,索引是什么?有什么用,以及建立索引时的一些技巧,还着重说了,索引的重要性。那么索引这么重要,在平时编码时如何避免呢?以下是我个人的建议:

  1. 在建表时就应该考虑添加索引,如:外键字段,等等。

  2. 在写完SQL后,一定要查看执行计划。尽量避免全表扫描。

  3. 如果是已有表中添加索引,一定要先计算该字段的区分度。

  4. 联合索引,将区分度大放在前面。

  5. 遵从MySQL左列前缀优先原则\

[2]H. Berenson, P. Bernstein, J. Gray, J.Melton, E. O’Neil,and P. O’Neil. A critique of ANSI SQL isolation levels. InProceedings of the SIGMOD International Conference on Management of Data, pages1–10, May 1995.

[3]Michael J. Cahill, Uwe Röhm, and Alan D.Fekete. 2008. Serializable isolation for snapshot databases. In SIGMOD ’08:Proceedings of the 2008 ACM SIGMOD international conference on Management of data, pages 729–738, New York, NY, USA. ACM.

[4]Michael James Cahill. 2009. Serializable Isolation for Snapshot Databases. Sydney Digital Theses. University of Sydney, School of Information Technologies

[5] A. Fekete, D. Liarokapis, E. O’Neil, P.O’Neil, andD. Shasha. Making snapshot isolation serializable. www.codexueyuan.com In ACM transactions on database systems, volume 39(2), pages 492–528, June 2005.

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
4月前
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
4月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
179 4
|
6月前
|
存储 关系型数据库 MySQL
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
|
8月前
|
关系型数据库 MySQL 数据库
Mysql的索引
MYSQL索引主要有 : 单列索引 , 组合索引和空间索引 , 用的比较多的就是单列索引和组合索引 , 空间索引我这边没有用到过 单列索引 : 在MYSQL数据库表的某一列上面创建的索引叫单列索引 , 单列索引又分为 ● 普通索引:MySQL中基本索引类型,没有什么限制,允许在定义索引的列中插入重复值和空值,纯粹为了查询数据更快一点。 ● 唯一索引:索引列中的值必须是唯一的,但是允许为空值 ● 主键索引:是一种特殊的唯一索引,不允许有空值 ● 全文索引: 只有在MyISAM引擎、InnoDB(5.6以后)上才能使⽤用,而且只能在CHAR,VARCHAR,TEXT类型字段上使⽤用全⽂文索引。
|
4月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
134 2
|
11月前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN:指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询,帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标,如 `id`、`select_type`、`table`、`type`、`key` 等,并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
2413 10
|
5月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之,覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具,一旦正确使用,就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度,让覆盖索引成为数据库优化师傅们手中的尚方宝剑,既能够提升性能,又能够保持系统的整洁高效。
166 9
|
6月前
|
机器学习/深度学习 关系型数据库 MySQL
对比MySQL全文索引与常规索引的互异性
现在,你或许明白了这两种索引的差异,但任何技术决策都不应仅仅基于理论之上。你可以创建你的数据库实验环境,尝试不同类型的索引,看看它们如何影响性能,感受它们真实的力量。只有这样,你才能熟悉它们,掌握什么时候使用全文索引,什么时候使用常规索引,以适应复杂多变的业务需求。
183 12
|
10月前
|
存储 关系型数据库 MySQL
MySQL索引学习笔记
本文深入探讨了MySQL数据库中慢查询分析的关键概念和技术手段。
699 81
|
7月前
|
SQL 存储 关系型数据库
MySQL选错索引了怎么办?
本文探讨了MySQL中因索引选择不当导致查询性能下降的问题。通过创建包含10万行数据的表并插入数据,分析了一条简单SQL语句在不同场景下的执行情况。实验表明,当数据频繁更新时,MySQL可能因统计信息不准确而选错索引,导致全表扫描。文章深入解析了优化器判断扫描行数的机制,指出基数统计误差是主要原因,并提供了通过`analyze table`重新统计索引信息的解决方法。
208 3

推荐镜像

更多