mysql索引

mysql索引,第1张

在mysql中,索引是一种特殊的数据库结构,由数据表中的一列或多列组合而成,可以用来快速查询数据表中有某一特定值的记录。

通过索引,查询数据时不用读完记录的所有信息,而只是查询索引列即可。

通过索引,查询数据时不用读完记录的所有信息,而只是查询索引列。否则,数据库系统将读取每条记录的所有信息进行匹配。

可以把索引比作新华字典的音序表。例如,要查“库”字,如果不使用音序,就需要从字典的 400 页中逐页来找。但是,如果提取拼音出来,构成音序表,就只需要从 10 多页的音序表中直接查找。这样就可以大大节省时间。

因此,使用索引可以很大程度上提高数据库的查询速度,还有效的提高了数据库系统的性能。

索引的优缺点

索引有其明显的优势,也有其不可避免的缺点。

优点

索引的优点如下:

1、通过创建唯一索引可以保证数据库表中每一行数据的唯一性。

2、可以给所有的 MySQL 列类型设置索引。

3、可以大大加快数据的查询速度,这是使用索引最主要的原因。

4、在实现数据的参考完整性方面可以加速表与表之间的连接。

5、在使用分组和排序子句进行数据查询时也可以显著减少查询中分组和排序的时间

缺点

增加索引也有许多不利的方面,主要如下:

1、创建和维护索引组要耗费时间,并且随着数据量的增加所耗费的时间也会增加。

2、索引需要占磁盘空间,除了数据表占数据空间以外,每一个索引还要占一定的物理空间。如果有大量的索引,索引文件可能比数据文件更快达到最大文件尺寸。

3、当对表中的数据进行增加、删除和修改的时候,索引也要动态维护,这样就降低了数据的维护速度。

使用索引时,需要综合考虑索引的优点和缺点。

MySQL 前缀索引能有效减小索引文件的大小,提高索引的速度。但是前缀索引也有它的坏处:MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引,也不能把它们用作覆盖索引(Covering Index)。

集一个索引包含多个列(最左前缀匹配原则)

索引列的值必须唯一,但允许有空值

全文索引为FUllText,在定义索引的列上支持值的全文查找,允许在这些索引列中插入重复值和空值,全文索引可以在CHAR,VARCHAR,TEXT类型列上创建

设定主键后数据会自动建立索引,InnoDB为聚簇索引

即一个索引只包含单个列,一个表可以有多个单列索引

覆盖索引是指一个查询语句的执行只用从所有就能够得到,不必从数据表中读取,覆盖索引不是索引树,是一个结果,当一条查询语句符合覆盖索引条件时候,MySQL只需要通过索引就可以返回查询所需要的数据,这样避免了查到索引后的回表 *** 作,减少了I/O效率

查看索引

列名解析:

删除索引

查看:

删除前:

删除后:

普通的索引,没有什么介绍

查看:(注意和前缀索引Sub_part的区别)

当索引的列是unique的时候,会生成唯一索引,唯一索引关于null有下列两种情况

SQLSERVER 下的唯一索引的列,允许null值,但最多允许有一个空值

MYSQL下的唯一索引的列,允许null值,并且允许多个空值

查看:

会建立两个索引,一个非聚簇索引,一个是唯一索引

结果:

可以插入两个空值(明人不说暗话,我喜欢MySQL)

一方面,它不会索引所有字段所有字符,会减小索引树的大小.

另外一方面,索引只是为了区别出值,对于某些列,可能前几位区别很大,我们就可以使用前缀索引。

一般情况下某个前缀的选择性也是足够高的,足以满足查询性能。对于BLOB,TEXT,或者很长的VARCHAR类型的列,必须使用前缀索引,因为MySQL不允许索引这些列的完整长度。

查看:

查看:

复合索引的最左前缀匹配原则

对于复合索引,查询在一定条件才会使用该索引

减少开销。 建一个联合索引(col1,col2,col3),实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引,都会增加写 *** 作的开销和磁盘空间的开销。对于大量数据的表,使用联合索引会大大的减少开销!

覆盖索引。 对联合索引(col1,col2,col3),如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么MySQL可以直接通过遍历索引取得数据,而无需回表,这减少了很多的随机io *** 作。减少io *** 作,特别的随机io其实是dba主要的优化策略。所以,在真正的实际应用中,覆盖索引是主要的提升性能的优化手段之一。

效率高。 索引列越多,通过索引筛选出的数据越少。有1000W条数据的表,有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据,如果只有单值索引,那么通过该索引能筛选出1000W10%=100w条数据,然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据,然后再排序,再分页;如果是联合索引,通过索引筛选出1000w10% 10% *10%=1w。

在模糊搜索中很有效,搜索全文中的某一个字段,可以参考这篇博文

: https://zhuanlan.zhihu.com/p/88275060

我们先进行下面一个实验看看InnoDB下的主键索引的一个现象。

查看:

我们插入进去的时候,数据的id都是乱序的,为什么这里最后select查询出来的结果都是进行了排序?

这是因为InnoDB索引底层实现的是B+tree,B+tree具有下列的特点:

所以上面的排序是为了使用B+tree的结构 ,B+tree为了范围搜索,将主键按照从小到大排序后,拆分成节点。后续还有新的节点进入的时候,和B-tree相同的 *** 作,会进行分裂。

一般来说,聚簇索引的B+tree都是三层

InnoDB中主键索引一定是聚簇索引,聚簇索引一定是主键索引。

为什么这里辅助索引叶子结点不直接存储数据呢?

MYISAM只有非聚簇索引,索引最终指向的都是物理地址。

Q:既然有回表的存在,那么聚簇索引的优势在哪里?

Q:主键索引作为聚簇索引需要注意什么

在查询语句中使用LIke关键字进行查询时,如果匹配字符串的第一个字符为"%",索引不会使用。如果“%”不是在第一位,索引就会使用

多列索引是在表的多个字段上创建的索引,满足最左前缀匹配原则,索引才会被使用

查询语句只有Or关键字时候,如果OR前后的两个条件都是索引,这这次查询将会使用索引,否则Or前后有一个条件的列不是索引,那么查询中将不使用索引

我们可以通过查看索引的属性来判断创建索引的方法。

查看索引的语法格式如下:

SHOW INDEX FROM <表名>[ FROM <数据库名>]

语法说明如下:

<表名>:指定需要查看索引的数据表名。

<数据库名>:指定需要查看索引的数据表所在的数据库,可省略。比如,SHOW INDEX FROM student FROM test语句表示查看 test 数据库中 student 数据表的索引。

示例

使用 SHOW INDEX 语句查看《MySQL创建索引》一节中 tb_stu_info2 数据表的索引信息,SQL 语句和运行结果如下所示。

mysql>SHOW INDEX FROM tb_stu_info2\G

1. row

Table: tb_stu_info2

Non_unique: 0

Key_name: height

Seq_in_index: 1

Column_name: height

Collation: A

Cardinality: 0

Sub_part: NULL

Packed: NULL

Null: YES

Index_type: BTREE

Comment:

Index_comment:

1 row in set (0.03 sec)

其中各主要参数说明如下:

参数 说明

Table 表示创建索引的数据表名,这里是 tb_stu_info2 数据表。

Non_unique 表示该索引是否是唯一索引。若不是唯一索引,则该列的值为 1;若是唯一索引,则该列的值为 0。

Key_name 表示索引的名称。

Seq_in_index 表示该列在索引中的位置,如果索引是单列的,则该列的值为 1;如果索引是组合索引,则该列的值为每列在索引定义中的顺序。

Column_name 表示定义索引的列字段。

Collation 表示列以何种顺序存储在索引中。在 MySQL 中,升序显示值“A”(升序),若显示为 NULL,则表示无分类。

Cardinality 索引中唯一值数目的估计值。基数根据被存储为整数的统计数据计数,所以即使对于小型表,该值也没有必要是精确的。基数越大,当进行联合时,MySQL 使用该索引的机会就越大。

Sub_part 表示列中被编入索引的字符的数量。若列只是部分被编入索引,则该列的值为被编入索引的字符的数目;若整列被编入索引,则该列的值为 NULL。

Packed 指示关键字如何被压缩。若没有被压缩,值为 NULL。

Null 用于显示索引列中是否包含 NULL。若列含有 NULL,该列的值为 YES。若没有,则该列的值为 NO。

Index_type 显示索引使用的类型和方法(BTREE、FULLTEXT、HASH、RTREE)。

Comment 显示评注。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5898901.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-07
下一篇 2023-03-07

发表评论

登录后才能评论

评论列表(0条)

保存