Mysql索引
A、索引的基本操作
1、概念
1)、查看索引 show index from 数据库表名
2)、alter table 数据库表 add index 索引名称(数据库表字段名称)
2、索引类型:
1)、PRIMARY KEY(主键索引)
ALTER TABLE table_name ADD PRIMARY KEY ( column )
2)、UNIQUE(唯一索引)
ALTER TABLE table_name ADD UNIQUE (column)
3)、INDEX(普通索引)
ALTER TABLE table_name ADD INDEX index_name ( column )
4)、FULLTEXT(全文索引)
ALTER TABLE table_name ADD FULLTEXT ( column )
5)、多列索引
ALTER TABLE table_name ADD INDEX index_name ( column1, column2, column3 )
3、操作
1).普通索引。
这是最基本的索引,它没有任何限制。它有以下几种创建方式:
(1)创建索引:
CREATE INDEX indexName ON tableName(tableColumns(length));
如果是CHAR,VARCHAR类型,length可以小于字段实际长度;如果是BLOB 和 TEXT 类型,必须指定length,下同。
(2)修改表结构:
ALTER tableName ADD INDEX [indexName] ON (tableColumns(length))
(3)创建表的时候直接指定:
CREATE TABLE tableName ( […], INDEX [indexName] (tableColumns(length)) ;
2).唯一索引。
它与前面的”普通索引”类似,不同的就是:索引列的值必须唯一,但允许有空值。如果是组合索引,则列值的组合必须唯一。它有以下几种创建方式:
(1)创建索引:
CREATE UNIQUE INDEX indexName ON tableName(tableColumns(length))
(2)修改表结构:
ALTER tableName ADD UNIQUE [indexName] ON (tableColumns(length))
(3)创建表的时候直接指定:
CREATE TABLE tableName ( […], UNIQUE [indexName] (tableColumns(length));
3).主键索引
它是一种特殊的唯一索引,不允许有空值。一般是在建表的时候同时创建主键索引:
CREATE TABLE testIndex(i_testID INT NOT NULL AUTO_INCREMENT,vc_Name VARCHAR(16) NOT NULL,PRIMARY KEY(i_testID)); 当然也可以用ALTER命令。
B、索引的原理及案例
主键是逻辑键,索引是物理键,意思就是主键不实际存在,而索引实际存在在数据库中
索引会真正的产生一个文件的,数据会真正的产生一个文件的
redo log 记录的是物理日志"某个数据页上做了什么修改" 循环使用
bin log 记录的是逻辑日志 语句的原始逻辑"ID=1 ,2 " 追加使用
而主键不会产生一个文件的 主键的搜索靠索引的树的搜索
数据的概念
数据有数据页的概念
mysql也有内存的概念 ,查询的时候 先看所在的数据页 是否在内存中 ,如果存在查询直接返回,如果不存在则去磁盘加载到内存再返回
所以更新操作
如果内存不存在 先去磁盘加载到内存然后修改后 再将值放入内存 ,并且再更新到redo log 日志表中
索引的原理
1.B+树索引 二叉搜索树这棵树是平衡二叉树 N叉树为了减少树高
如果语句是 select * from T where ID=500,即主键查询方式,则只需要搜索 ID 这棵 B+树
如果语句是 select * from T where k=5,即普通索引查询方式,则需要先搜索 k 索引树,ID 的值为 500,再到 ID 索引树搜索一次。这个过程称回表
也就是说,基于非主键索引的查询需要多扫描一棵索引树,因此,我们在应用中应该尽量使用主键查询。
2. 一个数据页满了,按照B+Tree算法,新增加一个数据页,叫做页分裂,会导致性能下降。空间利用率降低大概50%。
当相邻的两个数据页利用率很低的时候会做数据页合并,合并的过程是分裂过程的逆过程。
3.从性能和存储空间方面考量,自增主键往往是更合理的选择。
4.显然,主键长度越小,普通索引的叶子节点就越小,普通索引占用的空间也就越小。
因此自增主键比较合适
覆盖索引
create table T ( ID int primary key,
k int NOT NULL DEFAULT 0,
s varchar(16) NOT NULL DEFAULT '',
index k(k))
engine=InnoDB;
insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
select * from T where k between 3 and 5 这种查询K的索引搜索到主键 然后搜索主键的索引 拿到具体的信息有回表
覆盖索引
select ID from T where k between 3 and 5 这时只需要查 ID 的值,而 ID 的值已经在 k 索引树上了,因此可以直接提供查询结果,不需要回表 由于覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段。
最左前缀原则
索引(a,b) 查询条件b是无法使用联合索引的 查询条件a可以使用索引
%%开头是不会使用索引的
修改索引删除记录
alter table T engine=InnoDB
关于索引的题
CREATE TABLE `geek` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
PRIMARY KEY (`a`,`b`),
KEY `c` (`c`),
KEY `ca` (`c`,`a`),
KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;
由于历史原因,这个表需要 a、b 做联合主键
那意味着单独在字段 c 上创建一个索引,就已经包含了三个字段为什么要创建“ca”“cb”这两个索引?
select * from geek where c=N order by a limit 1;//和c的索引一样
select * from geek where c=N order by b limit 1;//和c的索引不一样
问题 这位同事的解释对吗? 哪些索引没有必要可以删除
表记录
–a--|–b--|–c--|–d--
1 2 3 d
1 3 2 d
1 4 3 d
2 1 3 d
2 2 2 d
2 3 4 d
主键 a,b 的聚簇索引组织顺序相当于 order by a,b ,也就是先按 a 排序,再按 b 排序,c 无序。
索引 ca 的组织是先按 c 排序,再按 a 排序,同时记录主键
–c--|–a--|–主键部分b-- (注意,这里不是 ab,而是只有 b)
2 1 3
2 2 2
3 1 2
3 1 4
3 2 1
4 2 3
上面的这个索引ca 与 索引c 的数据是一模一样的
索引 cb 的组织是先按 c 排序,在按 b 排序,同时记录主键
–c--|–b--|–主键部分a-- (同上)
2 2 2
2 3 1
3 1 2
3 2 1
3 4 1
4 3 2
所以结论是ca可以去掉 cb保留
常用的两种索引结构:B-tree和HASH
B-tree
B-tree索引能够加快访问数据的速度,因为存储引擎不再需要经行全表扫描来获取需要的数据,取而代之的是从根节点开始搜索。根节点的槽中存放了指向子节点的指针,存储引擎根据这些指针向下查找。通常比较节点页的值和要查找的值可以找到合适的指针进入下层子节点。
B-tree通常意味着所有的值都是按顺序存储的,并且每一个叶子页到根的距离相同。
如上图,是一颗B-tree,关于B-tree的定义可以参见B-tree,这里只说一些重点,浅蓝色的块我们称之为一个磁盘块,可以看到每个磁盘块包含几个数据项(深蓝色所示)和指针(黄色所示),如磁盘块1包含数据项17和35,包含指针P1、P2、P3,P1表示小于17的磁盘块,P2表示在17和35之间的磁盘块,P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据,只存储指引搜索方向的数据项,如17、35并不真实存在于数据表中。
B-tree的查找过程
如图所示,如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO,在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,29在26和30之间,锁定磁盘块3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分查找找到29,结束查询,总计三次IO。真实的情况是,3层的B-tree可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。
B-tree性质
- 通过上面的分析,我们知道IO次数取决于b+数的高度h,假设当前数据表的数据为N,每个磁盘块的数据项的数量是m,则有h=㏒(m+1) N,当数据量N一定的情况下,m越大,h越小;而m = 磁盘块的大小 / 数据项的大小,磁盘块的大小也就是一个数据页的大小,是固定的,如果数据项占的空间越小,数据项的数量越多,树的高度越低。这就是为什么每个数据项,即索引字段要尽量的小,比如int占4字节,要比bigint8字节少一半。这也是为什么B-tree要求把真实的数据放到叶子节点而不是内层节点,一旦放到内层节点,磁盘块的数据项会大幅度下降,导致树增高。当数据项等于1时将会退化成线性表。
- 当B-tree的数据项是复合的数据结构,比如(name,age,sex)的时候,b+数是按照从左到右的顺序来建立搜索树的,比如当(张三,20,F)这样的数据来检索的时候,B-tree会优先比较name来确定下一步的所搜方向,如果name相同再依次比较age和sex,最后得到检索的数据;但当(20,F)这样的没有name的数据来的时候,B-tree就不知道下一步该查哪个节点,因为建立搜索树的时候name就是第一个比较因子,必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时,B-tree可以用name来指定搜索方向,但下一个字段age的缺失,所以只能把名字等于张三的数据都找到,然后再匹配性别是F的数据了, 这个是非常重要的性质,即索引的最左匹配特性。
注意:B-tree的高度一般都在2-4层,这也就是说查找某一键值的行记录最多只要2到4次IO,花费0.02-0.04秒左右。B-tree索引适用于全值匹配、匹配最左前缀、匹配列前缀、匹配范围值
建立索引的原则
- 最左前缀匹配原则,非常重要的原则,mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整。
- =和in可以乱序,比如a = 1 and b = 2and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优化成索引可以识别的形式。
- 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少,唯一键的区分度是1,而一些状态、性别字段可能在大数据面前区分度就是0,那可能有人会问,这个比例有什么经验值吗?使用场景不同,这个值也很难确定,一般需要join的字段我们都要求是0.1以上,即平均1条扫描10条记录。
- 索引列不能参与计算,保持列“干净”,比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引,原因很简单,b+树中存的都是数据表中的字段值,但进行检索时,需要把所有元素都应用函数才能比较,显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
- 尽量的扩展索引,不要新建索引。比如表中已经有a的索引,现在要加(a,b)的索引,那么只需要修改原来的索引即可。
举例子:
数据表如下,
数据量:
我们通过explain查看执行计划
首先我们在没有添加索引时,进行如下查询。我们可以看出type=all表明全表扫描,估计查询行数为4070行。
我们通过explain查看执行计划
首先我们在没有添加索引时,进行如下查询。我们可以看出type=all表明全表扫描,估计查询行数为4070行。
现在我们添加索引如下,
在通过explain查询执行计划,我们发现该查询的行数估计为1行。
哈希索引
Mysql中只有在memory引擎显示支持哈希索引。
哈希索引基于哈希表实现,只有精确匹配索引所有列的列才有效。 对于每一行数据,存储引擎都会对所有索引计算一个哈希码,哈希码是一个较小的值并且不同键值计算出来的哈希码都不一样。哈希索引将所有的哈希码存储在索引中,同时在哈希表中保存指向每个数据的指针。
哈希索引的限制:
- 哈希索引只包含哈希值和行指针,而不知存储字段值,所以不能使用索引中的值来避免读取行(ID也必须回表)。若读取行,则必须进行行一次IO操作。
- 哈希索引并不是按照哈希值顺序存储的,所以也就无法用于排序。
- 哈希值也不支持部分索引,因为哈希值始终是使用索引列中所有的内容计算哈希值的。例如,在数据(A,B)上建立哈希索引,如果只查询A则不能使用哈希索引。
- 哈希索引只支持等值查询。
- 哈希索引查询速度非常快,除非出现出现冲突。
注意:Innodb引擎有一个特殊的功能叫做“自适应哈希索引”。当Innodb注意到某些索引值使用非常频繁时,它会在内存中基于B-tree索引之上再建立一个哈希索引。这是一个完全自动、内部的行为,用户无法配置或者设置,不过有必要可以关闭此功能。
创建自定义哈希索引
思路:在B-tree基础上创建一个伪哈希索引。这和真正的哈希索引不是一回事,它使用哈希值而不是键本身经行查找。需要在操作中在where语句中手动指定哈希函数。
其中,url_crc用来存储哈希值。该值根据url和哈希函数得出。
我们通过触发器来实现维护哈希值。
如果采用这种方式,记住不要使用SHA1()和MD5()作为哈希函数。因为这两个值计算出来的哈希值是非常长的字符串,会浪费大量时间,比较时也会比较慢。
在出现哈希冲突时,必须在子句中包含常量值。
Mysql常见的索引:主键索引、唯一索引、普通索引、全文索引、组合索引
1.唯一索引
与普通索引类似,不同的就是:索引列的值必须唯一,但允许有空值(注意和主键不同)。如果是组合索引,则列值的组合必须唯一。
例如,在已经存好数据的表中添加唯一索引,如果值有重复会报错,
2.主键索引
它是一种特殊的唯一索引,不允许有空值。
3.组合索引
平时用的SQL查询语句一般都有比较多的限制条件,所以为了进一步榨取MySQL的效率,就要考虑建立组合索引。
相当于同时创建了三个索引,
(ConutryCode,District,Name),(CountryCode,District),(CountryCode)。
这是因为从最左开始组合的。所以依次生成了三个索引。
3.全文索引
在前面描述中,在B-tree中可以通过列前缀进行查询。例如
select * from testwhere body=”hello%”;
然而,我们更普遍的查找方式是,
select * from testwhere body=”%hello%”;
全文索引可以支持各种字符在内的搜索,也支持自然语言搜索和布尔搜索。
注意,在innodb存储引擎中为了支持全文索引,必须有一列与word经行映射。在Innodb中这个列别命名为FTS_DOC_ID,其类型必须是BIGINT UNSIGNED NOT NULL,并且innodb存储引擎自动会在该列上加入一个名为FTS_DOC_ID_INDEX的unique index。上述操作都是由Innodb存储引擎自己完成的,用户也可在建表时手动添加FTS_DOC_ID以及相应的Unique idnex。
- 插入数据
- 建立全文索引
mysql> create fulltext index idx on fts(body);
可以看出每一个word都对应一个DOC_ID和POSITION。此外还记录了FIRST_ID,LAST_DOC_ID以及DOC_COUNT,分别代表了word第一次出现的文档ID,最后一次出现的文档ID,以及word在在多少个文档中存在。
全文索引的自然语言索引
自然语言索引引擎将计算每一个文档对象和查询的相关度。这里,相关度是指基于匹配的关键词个数,以及关键词在文档中出现的个数。
自然语言索引是默认的。
函数match()将返回关键词匹配的相关度,是一个浮点数字。
在match()中指定的列必须和全文索引中指定的列完全相同,否则无法只用全文索引。
举例子,
Boolen全文索引
Mysql数据库允许使用in boolen model修饰符来经行全文检索。当使用该修饰符时,查询字符串前后字符会有特殊含义。
Boolen全文检索支持以下几种操作符:
l +:表示word必须存在
l -:表示word必须不存在
l (no operator) 表示word是可选的。但是如果是可选的,其相关性会更高。
l @distance表示查询的多个单词之间的距离是否在distance之内。
2 rows in set(0.00 sec)
l >表示出现该word增加相关性
l <表示出现该word降低相关性
l ~允许出现该单词,但是出现时相关性为负。
l 表示以该单词开头的单词,如lik,表示可以是like,likes和lik
---------------+2 rows in set(0.00 sec)
l “表示短语
注意到,第一个against(“hello world“)是将hello和world当作两个单词经行查询。而第二个against(‘”hello world“’)是将这两个单词当作短语经行查询。
索引区别
普通索引:最基本的索引,没有任何限制
唯一索引:与"普通索引"类似,不同的就是:索引列的值必须唯一,但允许有空值。
主键索引:它是一种特殊的唯一索引,不允许有空值。
全文索引:针对较大的数据,生成全文索引很耗时好空间。
组合索引:为了更多的提高mysql效率可建立组合索引,遵循”最左前缀“原则。