如何构建高性能MySQL索引

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 RDS MySQL Serverless,价值2615元额度,1个月
简介: 原文:如何构建高性能MySQL索引介绍     上一篇文章中介绍了MySQL的索引基本原理以及常见的索引种类,这边文章的重点在于如何构建一个高性能的MySQL索引,从中你可以学到如何分析一个索引是不是好索引,以及如何构建一个好的索引。
原文: 如何构建高性能MySQL索引

介绍

    上一篇文章中介绍了MySQL的索引基本原理以及常见的索引种类,这边文章的重点在于如何构建一个高性能的MySQL索引,从中你可以学到如何分析一个索引是不是好索引,以及如何构建一个好的索引。

索引误区

多列索引

    一个索引的常见误区是为每一列创建一个索引,如下面创建的索引:

CREATE TABLE `t` (
  `c1` varchar(50) DEFAULT NULL,
  `c2` varchar(50) DEFAULT NULL,
  `c3` varchar(50) DEFAULT NULL,
  KEY `c1` (`c1`),
  KEY `c2` (`c2`),
  KEY `c3` (`c3`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


    t表里有三列,并且为每列创建了一个索引。创建索引的人为了能够快速访问表中的任何一列,因此为每一列添加了一个单独的索引。在多个列上创建索引通常并不能很好的提高MySQL查询性能,虽然说MySQL 5.0之后引入了索引合并策略,可以将多个单列索引合并成一个索引,但这并不总是有效的。同时创建多个索引的时候还会增加数据插入的成本,在插入数据的时候需要同时维护多个索引的写入操作。

 

索引的计算

    看下面这条sql语句:

select name from student where id + 1 = 5


    即使我们在student表的id列上建立索引,上面的这条SQL语句也无法使用索引。SQL语句中索引字段不能是表达式的一部分,也不能是函数的参数。

 

索引的长度以及选择性

    尽量不要在一个很长的列上使用索引,否则会导致索引占用的空间很大,同时在进行数据的插入和更新的时候意味着更慢的速度。因此使用uuid列作为索引并不是一个好的选择。从上一篇文章中我们可以知道,为了加快数据的访问索引是需要常驻内存的,假如说我们把64位uuid作为索引,那么随着表中数据量的增加索引的大小也在急剧增加。同时因为uuid并没有顺序性,因此在数据插入的时候都需要从根节点找到当前索引的插入位置,如果同一个节点中的索引大小达到上限,还会导致节点分裂,更加降低了插入速度。
    创建索引另外一个需要考虑的是索引的选择性,通常情况下我们会使用选择性高的列作为索引,但是也不一定一直是这样,下一节会介绍如何权衡索引的选择性。

创建高性能索引

选择正确的索引顺序

    在选择索引的顺序的时候有一个原则:将索引选择性最高的列放在左侧,同时索引的顺序要与查询索引的顺序一致,并且要兼顾考虑排序和分组的需要。在一个多列B树多列中索引的顺序意味着索引首先按照最左侧的列进行排序,其次是第二列。所以无论是where语句还是order by语句都需要尽量满足这个顺序,这样才能更好的使用索引。

索引的选择性

    列的选择性高的含义是通过这一列能够更多的过滤掉无用的数据,举个极端的例子,如果把自增id建成索引那么它的选择性是最高的,因为会把无用的数据都过滤掉,只会剩下一条有效数据。我们可以通过下面的方式来简单衡量某一个列的选择性:

select count(distinct columnA)/count(*) as selectivity from table 


当上面的数据越大的时候意味着columnA的选择性越高。这种方式提供了一个衡量平均选择性的办法,但是也不一定是有效的,需要具体情况具体分析。

 

前缀索引

    当遇到特别长的列,但又必须要建立索引的时候可以考虑建立前缀索引。前缀索引的含义是把某一列的前N个字符作为索引,创建前缀索引的方式如下:

alter table test add key(columnA(5));


上面这个语句就是把columnA的前5个字符创建为前缀索引。前缀索引是一种使索引更小、更快的有效办法。但是前缀所有有一个缺点:MySQL无法使用前缀索引来做order by和group by,也无法使用前缀索引做覆盖扫描。

 

聚簇索引和非聚簇索引

聚簇索引

    聚簇索引代表一种数据的存储方式,表示同一个结构中保存了B-Tree索引和数据行。也就是说当建立聚簇索引的时候实际的数据行存放在索引的叶子节点上。这也决定了每个表只能有一个聚簇索引。
聚簇索引组织数据的方式如下图所示:

    从图中可以看到索引的叶子节点和数据行是存放在一起的,这样的好处是可以直接读取到数据行。在创建表的时候如果我们不显式指定聚簇索引,那么MySQL将会按照下面的逻辑来选择聚簇索引:首先会通过主键列来聚集数据,如果没有主键列那么会选择唯一的非空索引来替代。如果还没有这样的索引那么会隐式的创建一个主键列来作为聚簇索引。
    聚簇索引优点:
1、相关数据存放在一起,检索的时候降低IO的次数
2、数据访问更快
3、使用覆盖索引扫描的查询可以直接使用节点中的主键值
    在使用上面的优点的时候聚簇索引也有一定的缺点:
1、聚簇索引将数据聚集在一起限制了插入速度,插入速度比较依赖于主键的顺序
2、更新索引的时候代价会变高
3、二级索引的访问的时候需要查找两次

非聚簇索引

    非聚簇索引通常被称为二级索引,与聚簇索引的不同在于,非聚簇索引的叶子节点存放的是数据的行指针或者是一个主键值。这样在查找数据的时候首先定位到叶子节点上的主键值(或者行指针),然后通过主键值再到聚簇索引中查找到对应的数据。从中我们可以看到对于非聚簇索引的查询需要走两次索引。下图是一个非聚簇索引:

    这个索引是InnoDB中的耳机索引,叶子节点中存储的是索引和主键。对于MyISAM叶子节点存储的是索引和行指针。

覆盖索引

    如果一个索引包含或者说覆盖所有需要查询的字段的值,那么就称为覆盖索引。覆盖索引可以极大的提高查询的效率,如果我们的查询中只查询索引,而不用去回表那应该最好不过了。
    通常我们使用explain关键字来查看一个查询语句的执行计划,通过执行计划我们可以了解到查询的细节。如果是覆盖索引,我们会看到执行计划的Extra列里有”Using Index”的信息。在查询语句中一般我们希望是where条件中的语句尽量能被覆盖,并且顺序要跟索引的保持一致。还有一个需要注意的点是MySQL不能在索引中使用like操作,这样会导致后面的索引失效。

后记

    本文主要讲了几种索引的原理以及如何构建一个高性能的索引。索引的优先是一个渐进的过程,随着数据量和查询语句的不同而发生变化,重要的是了解索引的原理,这样做出正确的优化。下一篇文章中将会介绍explain关键字,教你如何来看执行计划,以及如何判断一个查询语句是否需要优化的。

----------------------------------------------------------------

欢迎关注我的微信公众号:yunxi-talk,分享Java干货,进阶Java程序员必备。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
7天前
|
存储 关系型数据库 MySQL
Mysql索引总结(1)
Mysql索引总结(1)
15 0
|
6天前
|
SQL 存储 关系型数据库
MySQL索引基础篇
MySQL索引基础篇
19 0
|
3天前
|
存储 关系型数据库 MySQL
MySQL 8 索引原理详细分析
了解索引的详细原则,不仅有助于优化,能把索引搞清楚的,面试中优势也会很突显。 关于数据库优化的话题,V哥觉得还有很多地方可以聊,如果你有兴趣,欢迎关注一起讨论。
MySQL 8 索引原理详细分析
|
3天前
|
存储 关系型数据库 MySQL
Mysql学习--深入探究索引和事务的重点要点与考点
Mysql学习--深入探究索引和事务的重点要点与考点
|
4天前
|
存储 关系型数据库 MySQL
|
4天前
|
关系型数据库 分布式数据库 数据库
VLDB顶会论文解读 | PolarDB MySQL高性能强一致集群核心技术详解
在VLDB2023会议上,阿里云瑶池数据库团队的论文介绍了PolarDB-SCC,这是一个创新的云原生数据库系统,确保了低延迟的全局强一致读取。PolarDB-SCC解决了传统主从架构中只读节点可能返回过期数据的问题,实现了在不影响性能的情况下提供强一致性。通过重新设计的主从信息同步机制、线性Lamport时间戳和细粒度修改跟踪,以及利用RDMA优化的日志传输,PolarDB-SCC已经在PolarDB中成功应用超过一年,成为业界首个无感知全局一致性读的云原生数据库解决方案。
|
4天前
|
SQL 关系型数据库 MySQL
MySQL索引进阶篇
MySQL索引进阶篇
14 1
|
5天前
|
缓存 关系型数据库 MySQL
【专栏】MySQL高可用与性能优化——从索引到事务
【4月更文挑战第27天】本文探讨了提升MySQL性能和高可用性的策略,包括索引优化、查询优化和事务管理。通过合理使用B-Tree和哈希索引,避免过度索引,以及优化查询语句和利用查询缓存,可以改善性能。事务管理中,应减小事务大小并及时提交,以保持系统效率。主从或双主复制可增强高可用性。综合运用这些方法,并根据实际需求调整,是优化MySQL的关键。
|
6天前
|
关系型数据库 MySQL 数据库
【MySQL】数据库索引(简单明了)
【MySQL】数据库索引(简单明了)
|
6天前
|
Java 关系型数据库 MySQL
{MySQL}索引事务和JDBC
{MySQL}索引事务和JDBC
16 0