MySQL数据库索引
MySQL数据库索引
一：索引概述
索引是一种高效获取数据的数据结构，能够加快数据库的查询速度。
优点：
高效的获取数据，降低数据库的IO成本
通过索引列对数据进行排序操作，降低数据的排序成本，降低cpu的消耗
缺点：
索引列也是要占用空间
索引大大提高了查询速率，同时也降低更新表的速度。
二： 索引的数据结构
2.1 二叉查找树
二叉查找树的特点：
每个节点最多有2个分叉，左子树和右子树数据顺序左小右大。
这种特点是为了每次查找都可以折半而减少IO次数，因此对根节点选择要求比较高。
二叉查找树缺点：
当顺序插入时，会形成一个链表，查询性能大大降低。大数据量情况下，层级较深，检索速度慢。
2.2 平衡二叉树
平衡二叉树(AVL树)是特殊的二叉查找树，特殊的地方在于左右子树的高度之差绝对值不超过1，而且左右子树又是一棵平衡二叉树。
平衡二叉树的特点：
平衡二叉树采用二分法思维，平衡二叉查找树除了具备二叉树的特点，最主要的特征是树的左右两个子树的层级最多相差1。在插入删除数据时通过左旋/右旋操作保持二叉树的平衡，不会出现左子树很高、右子树很矮的情况。
使用平衡二叉查找树查询的性能接近于二分查找法。
平衡二叉树的缺点：
时间复杂度和树的高度有关。树有多高就需要检索多少次，每个节点的读取，都对应一次磁盘IO操作。在表数据量大时，查询性能就会很差。
2.3 B树：
MySQL的数据是存储在磁盘文件中的，查询处理数据时，需要先把磁盘中的数据加载到内存中，磁盘IO操作非常耗时，所以优化的重点就是尽量减少磁盘IO操作。访问二叉树的每一个节点就会发生一次IO,如果要减少磁盘的IO操作，就需要尽量降低树的高度。
在MySQL的InnoDB存储引擎一次IO会读取一页（默认16K）的数据量，而二叉树一次IO有效数据量只有很少的字节（例如：一个key,两个指针，每个指针4个字节，key取决于索引的类型。当key为bigint时，占用（8+4*2）个字节。）
为了减少浪费，可以在每个节点尽可能多的存储数据。将二叉树改造成多叉树，通过增加树的叉树，将树从高瘦变为矮胖。这样磁盘的IO次数变少了，查询数据的效率也就提高了。这种树叶叫做B树。
B树的特点
- B树的节点中存储着多个元素，每个内节点有多个分叉
- 节点中的元素包含键值和数据，节点中的键值从大到小排序。也就是说，在所有的节点都存储数据。
- 父节点中的元素不出现在子节点中。
- 所有的叶子节点都位于同一层，叶节点具有相同的深度，叶节点之间没有指针相连接。
读取数据的过程：
B树不支持范围查询的快速查找，你想想这么一个情况如果我们想要查找10和35之间的数据，查找到15之后，需要回到根节点重新遍历查找，需要从根节点进行多次遍历，查询效率有待提高。
如果data存储的是行记录，行的大小随着列数的增多，所占空间会变大。这时，一个页中可存储的数据量就会变少，树相应就会变高，磁盘IO次数就会变大。
2.4 B+树
B+树，作为B树的升级版，在B树基础上，继续改造。B+树和B树最主要的区别在与非叶子节点是否存储数据。
- B树： 非叶子节点和叶子节点都会存储数据。
- B+树： 只有叶子节点才会存储数据，非叶子节点至只存储键值。叶子节点之间使用双向指针连接，最底层的叶子节点形成一个双向有序链表。
对典型的B+Tree进行了优化。在原B+Tree的基础上增加了一个指向相邻叶子节点的列表指针，形成带有顺序指针的B+Tree,提高区间访问性能。
区间查找例子：
等值查找例子
B+树可以保证等值和范围查询的快速查找，MySQL的索引就采用了B+树的数据结构。
2.4 Hash表
hash索引就采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储到hash表中。出现hash冲突，可以通过列表解决。以键值对的形式存储数据。
缺点：
hash索引只能用于对等比较（=，in）,不支持范围查询
无法利用索引完成排序操作
优点：
查询效率高，通常只需要一次检索就可以了，效率通常要高于B+tree索引。
显然这种并不适合作为经常需要查找和范围查找的数据库索引使用。
InnoDB中具有自适应hash功能，hash索引是存储引擎根据B+Tree索引在指定条件下自动构造的。
2.5 为什么INNDB存储引擎选择使用B+tree索引结构
- 相对于二叉树，层级更少，搜索效率高。
- 对于B树,无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只要增加数的高度，导致性能降低。
- 相对于hash索引，不支持范围查询
三：索引的类型
3.1、主键索引
索引列中的值必须是唯一的，不允许有空值。
3.2、唯一索引
索引列中的值必须是唯一的，但是允许为空值
3.3、常规索引
MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值。
3.4、全文索引
只能在文本类型CHAR,VARCHAR,TEXT类型字段上创建全文索引.字段长度比较大时，如果创建普通索引，在进行like模糊查询时效率比较低，这时可以创建全文索引。MyISAM和InnoDB中可以使用全文索引。
3.5、空间索引
MySql在5.7之后的版本支持了空间索引，而且支持OPenCIS几何数据模型
3.6、前缀索引
在文本类型如CHAR,VARCHAR、TEXT类列上创建索引时，可以指定索引列的长度，但是数值类型不能确定。
1)物理分类
1、聚簇索引
聚簇是为了提高某个属性(或属性组)的查询速度，把这个或这些属性上具有相同值的元祖集中存放在连续的物理块。这种存储方式依靠B+树来实现的，根据表的主键构造一棵B+树且B+树叶子节点存放的都是表的行记录数据时，方可称主键索引为聚簇索引。可以理解为将数据存储与索引放到了一块，找到索引，也就找到了数据。
2、二级索引
将数据与索引分开存储。B+树叶子节点存放的不是数据表的行记录。
查找整条记录需要回表查询。
MyISAM表的索引和数据是分开存储的，.MYD表数据文件，.MYI表索引文件。
虽然InnoDB 和MyISAM存储引擎都默认使用B+树结构存储索引，但是只有InnoDB的主键索引才是聚簇索引，InnoDB中的辅助索引以及MyISAM使用的都是二级索引。每张表最多只能拥有一个聚簇索引。
InnoDB 叶子节点存储行记录，是一条完整的数据，MyISAM叶子节点存储记录指针。
覆盖索引
什么是覆盖索引？
MySQL官网，explain的输出结果Extra字段为Using index时，能够触发索引覆盖。
覆盖索引不是索引类型，是数据查询的一种方式。
总之：只需要在一棵索引树上就能够获取SQL所需的所有列数据，无需回表，速度更快。
怎样实现索引覆盖？
常见的方式是：通过建立复合索引覆盖被查询的字段。
#例如
`create table user(`
`id int primary key`，
name varchar(20)，
sex varchar(5)，
index(name，sex)
)engine=innodb;
#查询语句
explain select id,name,sex from user where name ='lala'
此时可以命中索引覆盖，不需要进行回表查找sex字段。
2)按照索引列数量
1、单列索引
一个索引只包含一个列，一个表可以有多个单列索引。
2、组合索引
组合索引的使用，需要遵循最左前缀匹配原则。在条件允许的情况下，使用组合索引替代多个单列索引使用。
四：索引的使用：
4.1 创建索引
4.1.1 添加PRIMARY KEY(主键索引)
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
4.1.2 添加UNIQUE(唯一索引)
ALTER TABLE `table_name` ADD UNIQUE ( `column` )
4.1.3 添加INDEX(普通索引)
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
4.1.4 添加FULLTEXT(全文索引)
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
4.1.5 添加多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
4.2 修改索引
mysql中没有真正意义上的修改索引，只有先删除之后在创建新的索引才可以达到修改的目的，原因是mysql在创建索引时会对字段建立关系长度等，只有删除之后创建新的索引才能创建新的关系保证索引的正确性；
4.3 删除索引
格式：DROP INDEX 索引名称 ON 表名;
DROP INDEX login_name_index ON `user`;
4.4 查询索引
格式：SHOW INDEX FROM 表名;
SHOW INDEX FROM `user`;
五: SQL性能分析
5.1 慢查询日志
慢查询日志记录了所有执行时间超过指定参数的SQL语句的参数。
（long_quert_time，单位：秒，默认为10秒）
MYSQL的慢查询日志默认没有开启，需要在MYSQL的配置文件中（/etc/my.cnf）中配置如下信息：
#查看慢查询日志参数
show variables like 'slow_query_log';
#修改MYSQL的配置信息（linux系统）
vi /etc/my.cnf
#添加一下配置信息
#开启MYSQL慢查询的日志开关
slow_query_log = 1
#设置慢查询日志的时间为2秒，SQL语句的执行时间超过2秒时视为慢查询语句，记录慢查询日志。
login_query_time = 2
##配置完成后重启数据库
service mysql restart
systemctl restart mysql
此时在mysql目录下（datadir的配置目录下）会生成
localhost-slow.log 文件
cat localhost-slow.log 查看SQL日志
tail -f localhost-slow.log 实时查看SQL日志的尾部
5.2 SQL的执行频率
MYSQL客户端连接成功之后可以通过 show[ session|global ] status 命令查看服务器的状态信息。
#查看服务器 insert，update，delete，select的访问次数
show global status like 'com_______';
#七个下划线，代表七个字符
5.3 profile详情
show profiles 能够在做SQL优化时帮助我们了解时间的耗费。
可以通过 have_profiling 参数。
需要查看MYSQL版本是否支持
profile操作
SELECT @@have_profiling ;
##默认profiling是关闭的，可以通过set语句在session/gloal级别开启profiling:
SET profiling =1 ;
##可以通过语句查询是否开启
SELECT @@@profiling;
1 是开启
2 是关闭
查看每一条SQL语句的耗时情况
show profiles;
查看指定 query_id 的 SQL 语句的各个阶段的耗时情况
show profile for query query_id;
查看指定query_id 的SQL语句各个阶段的CPU的使用情况
show profile cpu for query query_id;
5.4 explain 执行计划 （重要）
explain 或者 desc 命令 可以获取到 MYSQL 如何执行 select 语句的信息，包括在select 语句执行的过程中表是如何连接以及连接的顺序。
语法：
#直接在sql语句之前加上关键字 explain/desc
explain select 字段名 from 表名 where 条件;
explain执行计划各个字段的含义
id
select 查询的序列号，表示查询中执行select子句或者操作表的顺序
id相同，执行顺序从上到下,
id不相同，值越大，越先执行。
select_type
表示select 的类型，常见的取值有
SLMPLE(简单表，即不适用表连接或者子查询)
PRIMARY (主查询，即外层的查询)
UNION(UNION中的第二个或者后面的查询语句)
SUBQUERY(select/where 之后包含的子查询)
type（重要）
表示连接类型，性能由好到差的连接类型为
NULL 、system 、const、 eq_ref、ref 、range、index、all。
唯一索引会出现 const
非唯一索引出现 ref
index 有索引，但是遍历所有的索引
possible_key
显示可能用到的这张表上的索引，一个或者多个。
key
实际使用的索引，如果为 null ，则没有使用索引
filtered
表示返回结果行数占需要读取行数的百分比，filtered 的值越大越好。
六：索引失效的情况：
6.1 使用!= 或者 <> 导致索引失效
SELECT * FROM `user` WHERE `name` != '冰峰';
我们给name字段建立了索引，但是如果!= 或者 <> 这种都会导致索引失效，进行全表扫描，所以如果数据量大的话，谨慎使用
可以通过分析SQL看到，type类型是ALL，扫描了10行数据，进行了全表扫描。<>也是同样的结果
6.2 类型不一致导致的索引失效
SELECT * FROM `user` WHERE height= 175;
height表字段类型是varchar，但是我查询的时候使用了数字类型，因为这个中间存在一个隐式的类型转换，所以就会导致索引失效，进行全表扫描。
6.3 函数导致的索引失效
SELECT * FROM `user` WHERE DATE(create_time) = '2020-09-03';
当使用函数时索引失效。
6.4 运算符导致的索引失效
SELECT * FROM `user` WHERE age - 1 = 20;
如果你对列进行了（+，-，*，/，!）, 那么都将不会走索引。
6.5 OR引起的索引失效
SELECT * FROM `user` WHERE `name` = '张三' OR height = '175';
OR导致索引是在特定情况下的，并不是所有的OR都是使索引失效，如果OR连接的是同一个字段，那么索引不会失效，反之索引失效。
6.6 （前缀）模糊搜索导致的索引失效
SELECT * FROM `user` WHERE `name` LIKE '%冰';
模糊搜索如果你前缀也进行模糊搜索，那么不会走索引
6.7 IS NULL不走索引，IS NOT NULL走索引
#不走索引
SELECT * FROM `user` WHERE address IS NULL
# 走索引
SELECT * FROM `user` WHERE address IS NOT NULL;
根据这个情况，建议大家这设计字段的时候，如果没有必要的要求必须为NULL，那么最好给个默认值空字符串，这可以解决很多后续的麻烦
6.8 最左匹配原则
EXPLAIN SELECT * FROM `user` WHERE name = '冰峰' AND sex = '男';
啥叫最左匹配原则，就是对于符合索引来说，它的一个索引的顺序是从左往右依次进行比较的，像第二个查询语句，name走索引，接下来回去找age，结果条件中没有age那么后面的sex也将不走索引。
6.9 如果使用了!=会导致后面的索引全部失效
SELECT * FROM `user` WHERE sex = '男' AND `name` != '冰峰' AND age = 22;
我们在name字段使用了 != ，由于name字段是最左边的一个字段，根据最左匹配原则，如果name不走索引，后面的字段也将不走索引。
七：索引的使用原则：
1、 查询条件中频繁使用的字段适合建立索引
2 、数字型的字段适合建立索引
数字型字段与字符串字段在处理时，前者仅需比较一次就可以了，而后者则需要逐个比较字符串中的每一个字符。
3 、存储空间小的字段适合建立索引
4、 重复值较高的字段不适合建立索引
5 、更新频繁的字段不适合建立索引
对于建立索引的字段，数据在更新时，为了保证索引数据的准确性，同时还要更新索引。所以在字段被频繁更新时，会造成I/O访问量增加，影响系统的资源消耗，加重了存储负载。