本文源码：GitHub·点这里 || GitEE·点这里

一、高性能索引

1、查询性能问题

在MySQL使用的过程中，所谓的性能问题，在大部分的场景下都是指查询的性能，导致查询缓慢的根本原因是数据量的不断变大，解决查询性能的最常见手段是：针对查询的业务场景，设计合理的索引结构。

2、索引使用原则

索引的使用并不是越多越好，而是针对业务下的查询场景，不断的改进和优化，例如电商系统中用户订单的场景，假设存在如下表结构：

CREATE TABLE `ds_user` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',`user_name` varchar(20) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';CREATE TABLE `ds_order` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',`user_id` int(11) NOT NULL COMMENT '用户ID',`order_no` varchar(60) NOT NULL COMMENT '订单号',`product_name` varchar(50) DEFAULT NULL COMMENT '产品名称',`number` int(11) DEFAULT '1' COMMENT '个数',`unit_price` decimal(10,2) DEFAULT '0.00' COMMENT '单价',`total_price` decimal(10,2) DEFAULT '0.00' COMMENT '总价',`order_state` int(2) DEFAULT '1' COMMENT '1待支付，2已支付,3已发货,4已签收',`order_remark` varchar(50) DEFAULT NULL COMMENT '订单备注',`create_time` datetime DEFAULT NULL COMMENT '创建时间',PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单表';

用户和订单管理表，在电商的业务中很常见，可以通过对该业务分析，看看常用的索引结构：

用户方：

基于用户的查询，多数是基于用户ID(user_id)；
基于订单号(order_no)，查看物流的信息；

运营方：

基于时间段的流水明细(create_time)或排序;
基于订单状态的筛选(order_state)和统计；
基于产品(product_name)的数据统计分析；

这样一个流程分析走下来，即可以在开发初期，确定哪些结构是查询必须用到的，预先做好索引结构，避免数据量庞大到影响性能时再去考虑使用索引。

有些时候会考虑放弃一些查询条件，例如基于产品名称的数据统计，走定时任务的方式，用来缓解表的查询压力，处理的方式是多样的。

优秀的索引设计，都是建立在对业务数据的理解上，考虑业务数据的查询方式，提高查询效率。

二、索引创建

1、单列索引

单列索引，即索引建立在表的一个字段上，一个表可以有多个单列索引，使用起来相对比较简单：

CREATE INDEX user_id_index ON ds_order(user_id) USING BTREE;

主键索引，或者上述的user_id_index都是单列索引。

业务场景：基于用户自己对订单查询，和管理系统，订单和用户的关联查询，所以订单表的user_id需要一个索引。

2、组合索引

组合索引包含两个或两个以上的列，组合索引相比单列索引复杂很多，如何建立组合索引，和业务关联度非常高，在使用组合索引时，还需要考虑查询条件的顺序。

CREATE INDEX state_create_time_index ON `ds_order`(`create_time`,`order_state`);

如上就是组合索引，实际包含的是2个索引 (create_time) (create_time,order_state)，这样查询就涉及到最左前缀的原则，必须按照顺序来查询，这里下面详说。

业务场景：首先单说这里组合索引，在业务开发中，常见订单状态的统计，基于统计结果做运营分析，另外就是在运营系统中，基于创建时间段的筛选条件是默认存在的，避免全部数据实时扫描；一些其他的常见查询也都是条件加时间段的查询模式。

3、前缀索引

如果需要加索引的列是很长的字符串，那么索引会变的庞大臃肿，起到的效果可能并不是很明显。这时候可以截取列的前面一部分，创建索引，节省空间，这样可能会出现索引的选择性下降，即基于前缀索引查询出的相似数据可能很多：

ALTER TABLE ds_order ADD KEY (order_no(30)) ;

这里由于订单号太长，所以选择前面30位作为前缀索引，用作订单号的查询，当然这里涉及到一个非常经典的业务场景，订单号机制。

业务场景：前缀索引一个典型的应用场景就是处理订单号，一个看似很长的订单号，其实包含的信息非常多：

时间点：就是订单生成的时间，年月日时分秒；
标识位：即一个唯一的UID，保证订全单号唯一；
埋点一：在很多业务中，在订单号记录产品类目；
埋点二：通常会标识产品属性，例如颜色，口味等；
错位符：防止订单号被分析，会随机一段错位符号；

如此一段分析下来，实际订单号是非常长的，所以需要引入前缀索引机制，前缀索引期望使用的索引长度可以筛选整个列的基数，例如上面的订单号：

大部分业务基于时间节点筛选足够，即索引长度14位；
如果是并发业务，很多时间节点相同，则索引长度是时间点+标识位；

注意：如果业务允许的情况下，一般要求前缀索引的长度有唯一性，例如上面的时间和标示位。

4、其他索引

例如全文索引等，这些用到的场景不多，如果数据庞大，又需要检索等，通常会选择强大的搜索中间件来处理。显式唯一索引，这种也会在程序上做规避，避免不友好的异常被抛出。

三、索引查询

如何创建最优的索引，是一件不容易的事情，同样在查询的时候，是否使用索引也是一件难度极大的事情，经验之谈：多数是性能问题暴露的时候，才会回头审视查询的SQL语句，针对性能问题，做相应的查询优化。

1、单列查询

这里直接查询主键索引，MySQL的主键一般选择自增，所以速度非常快。

EXPLAIN SELECT * FROM ds_order WHERE id=2;
EXPLAIN SELECT * FROM ds_order WHERE id=1+1;
EXPLAIN SELECT * FROM ds_order WHERE id+1=1;

这里，id=2,id=1+1，MySQL都可以自动解析，但是id+1是在索引列上执行运算，直接导致主键索引失效。这里有一个基本策略，如果非要在单列索引上做操作，可以将该逻辑放在程序中，到MySQL层面，SQL语句越干净利落越好。

2、前缀索引查询

前缀索引的查询，可以基于Like对特定长度筛选，或者全订单号查询。

EXPLAIN SELECT * FROM ds_order WHERE order_no LIKE '202008011314158723628732871625%';
EXPLAIN SELECT * FROM ds_order WHERE order_no='20200801131415872362873287162572367';

3、组合索引查询

查询最麻烦的就是组合索引，或者说查询条件组合起来，都使用了索引：

EXPLAIN SELECT * FROM ds_order
WHERE create_time>'2020-08-01 00:00:00' AND order_state='1';

上述基于组合索引中列的顺序，使用了组合索引：state_create_time_index。

EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00';

上述只使用create_time列，也同样使用了索引结构。

EXPLAIN SELECT * FROM ds_order WHERE order_state='1';

上述如果只使用order_state条件，则结果显示全表扫描。

EXPLAIN SELECT * FROM ds_order
WHERE create_time>'2020-08-01 00:00:00' AND order_no LIKE '20200801%';

上述则基于组合索引的create_time列和单列索引order_no保证查询条件都使用了索引。

通过上面几个查询案例，索引组合索引使用的注意事项如下：

组合索引必须按索引最左列开始查询；
不能跳过组合字段查询,这样无法使用索引；

四、索引其他说明

1、索引的优点

基于注解或唯一索引保证数据库表中数据的唯一性；
索引通过减少扫描表的行数提高查询的效率；

2、索引的缺点

创建索引和维护索引，会耗费空间和实际；
查询以外的操作增删改等，都需要动态维护索引；

3、索引使用总结

索引机制在MySQL中真的非常复杂，非专业的DBA(就是指开发人员)，基本要熟练常见的索引结构，待过两年所谓的大厂，每个版本开发涉及的核心表SQL都是有专业DBA验收，复杂的查询都是提交需求，DBA直接输出查询SQL，当然在一般公司是没有DBA，需要开发在开发的过程中不断的思考，逐步优化，这需要对业务数据有一定的敏感度，对核心接口有执行监控，当发现稍微出现耗时情况，就可以不断优化，这个积累是个枯燥和进步的过程。

五、源代码地址

GitHub·地址
https://github.com/cicadasmile/mysql-data-base
GitEE·地址
https://gitee.com/cicadasmile/mysql-data-base

序号	文章标题
01	MySQL基础：经典实用查询案例，总结整理
02	MySQL基础：从五个维度出发，审视表结构设计
03	MySQL基础：系统和自定义函数总结，触发器使用详解
04	MySQL基础：存储过程和视图，用法和特性详解
05	MySQL基础：逻辑架构图解和InnoDB存储引擎详解
06	MySQL基础：事务管理，锁机制案例详解
07	MySQL基础：用户和权限管理，日志体系简介
01	MySQL进阶：基于多个维度，分析服务器性能
02	MySQL进阶：索引体系划分，B-Tree结构说明

MySQL进阶篇(03)：合理的使用索引结构和查询相关推荐

超详细图解！【MySQL进阶篇】存储过程,视图,索引,函数,触发器
超详细图解![MySQL进阶篇]存储过程,视图,索引,函数,触发器 1.1 下载Linux 安装包 1.2 安装MySQL 1.3 启动 MySQL 服务 1.4 登录MySQL 2\. 索引 2.1 ...
C#笔记进阶篇03 抽象函数与抽象类
C#笔记进阶篇03 抽象函数与抽象类 --本系列是基于人民邮电出版社<C#2008 C#图解教程>.清华大学出版社<C#入门经典(第五版)>两本书的自学C#笔记,如果您发现了本 ...
黑马MySQL进阶篇笔记
目录 MySQL进阶篇一.存储引擎 1.1 Mysql体系结构图 1.2 存储引擎 1.概念 2.InnoDB 3.MyISAM 4.Memory 5.三种引擎对比 6.引擎的选择 1.3 安装my ...
【MySQL | 进阶篇】07、全局锁、表级锁、行级锁
目录一.概述二.全局锁 2.1 介绍 A. 我们一起先来分析一下不加全局锁,可能存在的问题. B. 再来分析一下加了全局锁后的情况 2.2 语法 1). 加全局锁 2). 数据备份 3). 释放锁 ...
【MySQL进阶篇】学习笔记
文章目录 MySQL进阶学习前言 1.存储引擎 1.1 MySQL体系结构概览 1.2 存储引擎介绍 1.3 常见存储引擎的特点 1.3.1 InnoDB的特点 1.3.2 MyISAM 1.3.3 ...
【MySQL | 进阶篇】05、MySQL 视图、触发器讲解
目录一.视图 1.1 介绍 1.2 语法 1.2.1 演示示例 1.3 检查选项 1.3.1 CASCADED 级联 1.3.2 LOCAL 本地 1.3.3 示例演示 1.4 视图的更新 1.4. ...
Mysql进阶学习（四）分组函数与分组查询
Mysql进阶学习(四)分组函数与分组查询一.进阶4:分组函数 1.简单的使用 1.1 SUM 求和 1.2 AVG 求平均值 1.3MIN 最小值 1.4 MAX 最大值 1.5 COUNT求总数 ...
MySQL进阶篇(02)：索引体系划分，B-Tree结构说明
本文源码:GitHub·点这里 || GitEE·点这里一.索引简介 1.基本概念首先要明确索引是什么:索引是一种数据结构,数据结构是计算机存储.组织数据的方式,是指相互之间存在一种或多种特定关系 ...
超详细图解！【MySQL进阶篇】SQL优化-索引-存储引擎
1. Mysql的体系结构概览整个MySQL Server由以下组成 Connection Pool : 连接池组件 Management Services & Utilities : 管理 ...

MySQL进阶篇(03)：合理的使用索引结构和查询