菜单

MySQL版本详解

2018年11月16日 - MySQL

同、版本说明

MySQL的目详解,MySQL索引详解

1.1、MySQL相关连接

MySQL官网:https://www.mysql.com/

MySQL下载:https://dev.mysql.com/downloads/mirrors/

MySQL文档:https://dev.mysql.com/doc/relnotes/mysql/5.5/en/

证明:MySQL文档每种版本的mysql都来相应的文档。上面的例子是MySQL5.5之文档。

一. 索引基础

1.2、MySQL版本说明

  1. Alpha版
  2. Beta版
  3. RC版
  4. GA版
  5. Release版

1.1 简介

在MySQL中,索引(index)也称之为“键(key)”,它是储存引擎用于快速找到记录之同种多少结构。

目对于完美的性能非常重要,尤其是当表中之数据量越来越老时,索引对性能的影响就是进一步重要。

目录优化应该是本着查询性能优化最实惠的招数,创建一个着实最漂亮的目经常得重新写SQL查询语句。

1.3、MySQL版本号

  1. 率先只数字(5)主版本号:文件格式改动时,将用作新的版发布(5.5.60);
  2. 其次单数字(5)发行本号:新增特色或者转动不兼容时,发行版本号需要改变(5.5.60);
  3. 其三只数字(60)发行序列号:主要是略之更动,如bug的修补、函数添加或改动、配置参数的改动等(5.5.60)。

网设置使用MySQL版本查询办法:

  1. 登录MySQL方法
  2. 未记名直接询问艺术

1.2 索引的干活原理

倘若懂MySQL中索引的办事原理,最简便的法子就是是错过看无异扣押无异本书的目部分:比如你想在相同本书中找寻有主题,一般会预先看开的目录目录,找到相应之段、对应的页码后即得便捷找到您想看之情节。

于MySQL中,存储引擎用接近之艺术应用索引,其先在目录中找找对应的值,然后因匹配的目记录找到呼应的数额实行,最后用数据结果集返回给客户端。

仲、产品线说明

1.3 索引的种

每当MySQL中,通常我们所依的索引类型,有以下几种植:

2.1、版本号划分MySQL

  1. 3.X至5.1.X。
  2. 5.4.X到5.7.X。
  3. 6.0.X到7.1.X

1.4 索引的方

每当MySQL中,索引是当储存引擎层实现的,而非是以劳务器层。MySQL支持的目录方法,也可以说成是索引的种(这是广义层面达到的),主要发生以下几种植:

B-Tree 索引

使没有特别指明类型,那多半说的即使是B-Tree
索引。不同之仓储引擎以不同的方使B-Tree索引,性能也各不相同。例如:MyISAM使用前缀压缩技术使索引更有些,但InnoDB则按照原有之数格式存储索引。再设MyISAM通过数量的情理位置引用被索引的履,而InnoDB则根据主键引用被索引的行。

B-Tree
对索引列是顺序存储的,因此杀适合查找范围数据。它能够加速访问数的快慢,因为存储引擎不再要开展全表扫描来博取需要之数码。

万一一个目中连多独字段(列)的价值,那它们就是是一个复合索引。复合索引对多单字段值进行排序的依据是创建索引时列的顺序。如下:

create table people (
 id int unsigned not null auto_increment primary key comment '主键id',
 last_name varchar(20) not null default '' comment '姓',
 first_name varchar(20) not null default '' comment '名',
 birthday date not null default '1970-01-01' comment '出生日期',
 gender tinyint unsigned not null default 3 comment '性别:1男,2女,3未知',
 key(last_name, first_name, birthday)
) engine=innodb default charset=utf8;

people表中吗早已插入了如下一些数据:

id last_name first_name birthday gender
1 Clinton Bill 1970-01-01 3
2 Allen Cuba 1960-01-01 3
3 Bush George 1970-01-01 3
4 Smith Kim 1970-01-01 3
5 Allen Cally 1989-06-08 3

我们创建了一个复合索引 key(last_name, first_name,
birthday),对于表中的诸一行数,该索引中还含有了姓、名和出生日期这三排的价。索引也是因这顺序来排序存储的,如果某个片独人口的姓氏和名都一样,就会见根据他们的出生日期来对索引排序存储。

B-Tree
索引适用于全键值、键值范围要键前缀查找,其中键前缀查找就适用于依据绝荒唐前方缀查找。

复合索引对如下类型的查询有效:

全值匹配

全值匹配指的凡和目录中之享有列进行匹配。例如:查找姓Allen、名Cuba、出生日期为1960-01-01之人。

SQL语句为:

select id,last_name,first_name,birthday from people where last_name='Allen' and first_name='Cuba' and birthday='1960-01-01';

相当最荒唐前缀

论就使索引的率先排,查找所有姓为Allen的总人口。SQL语句也:

select id,last_name,first_name,birthday from people where last_name='Allen';

匹配配列前缀

遵只相当配索引的第一排列的价值的开端部分,查找所有姓氏为A开头的丁。SQL语句也:

select id,last_name,first_name,birthday from people where last_name like ‘A%';

匹配配范围值

遵循限制匹配姓氏于Allen和Clinton之间的人数。SQL语句也:

select id,last_name,first_name,birthday from people where last_name BETWEEN ‘Allen' And ‘Clinton';

此间为单独使了目录的第一列。

规范匹配第一排列并限制匹配后面的排

论寻找姓Allen,并且名字为字母C开头的人数。即全匹配复合索引的第一列,范围匹配第二列。SQL语句也:

select id,last_name,first_name,birthday from people where last_name = ‘Allen' and first_name like'C%';

只是看索引的询问

B-Tree
通常可以支撑“只看索引的查询”,即查询才待看索引,而不论需访问数据行。这和“覆盖索引”的优化相关,后面又道。

脚介绍一些复合索引会失效的景:

(1)如果无是依照复合索引的极端左列开始查找,则无从利用索引。例如:上面的例证中,索引无法用于查找查找名吧Cuba的人口,也束手无策搜索某个特定出生日期的人,因为就简单排列都不是复合索引
key(last_name, first_name, birthday)
的极致左数据列。类似地,也无能为力搜索姓氏以有字母结尾的人头,即like范围查询的混淆匹配符%,如果放在第一各项会使索引失效。

(2)如果找时过了了目录中的排列,则只有前的索引列会用到,后面的索引列会失效。比如寻找姓Allen且出生日期在有特定日期的人。这里追寻时,由于并未点名查找名(first_name),故MySQL只能使该复合索引的率先排(即last_name)。

(3)如果查询中有有列的限制查询,则该列右边的拥有列都无法利用索引优化查找。例如有查询条件为
where last_name=’Allen’ and first_name like ‘C%’ and
birthday=’1992-10-25’,这个查询只能利用索引的前片列,因为此处的 like
是一个限条件。假如,范围查询的排的值的数额少于,那么得经过动多只相当条件代替范围条件进行优化,来使右边的排也可以用到目录。

兹,我们解了复合索引中列的逐一是多的显要,这些限制都与索引列的各个有关。在优化性能的时节,可能得使用同一的列但顺序不同之目来满足不同品类的查询需要,比如当同样摆放表中,可能得简单个复合索引
key(last_name, first_name, birthday) 和 key(first_name, last_name,
birthday) 。

B-Tree索引是不过常用之索引类型,后面,如果无专门说明,都是靠的B-Tree索引。

1、哈希索引

哈希索引(hash
index)基于哈希表实现,只有规范匹配索引所有列的询问才有效。在MySQL中,只有Memory引擎显示支持哈希索引。

2、空间数据索引(R-Tree)

MyISAM引擎支持空中引得,可以视作地理数据存储。和B-Tree索引不同,该索引无须前缀查询。

3、全文索引

全文索引是同栽奇特类别的目录,它寻找的是文本中之要词,而非是直比较索引中之价值。全文索引和任何几种索引的配合方式了无一致,它再近乎于找引擎做的业务,而非是粗略的where条件匹配。可以当平的排列上,同时创造全文索引和B-Tree索引,全文索引适用于
Match Against 操作,而休是日常的where条件操作。

目录可以蕴涵一个排列(即字段)或多独列的价。如果找引包含多个列,一般会以那个誉为复合索引,此时,列的次第就老大首要,因为MySQL只能飞的以索引的尽荒唐前方缀列。创建一个分包两单列的目,和创办两独才包含一排列的目录是大不相同的。

2.2、根据使用场景划分

  1. MySQL Community Server
  2. MySQL Enterprise Edition
  3. MySQL Cluster
  4. MySQL Workbench(GUI TOOL)

  5. ①、分别是社区本(MySQL Workbench OSS)

  6. ②、商用版(MySQL Workbench SE)。

1.5 索引的亮点

目可以吃MySQL快速地查看找到我们所要之多少,但马上并无是索引的唯一作用。

无限普遍的B-Tree索引,按照顺序存储数据,所以,MySQL可以就此来举行Order
By和Group
By操作。因为数量是雷打不动存储的,B-Tree也就会见把有关的列值都存储在同步。最后,因为索引中吗蕴藏了实际的列值,所以某些查询才下索引就能够获取到任何之多寡,无需再次回表查询。据此特点,总结出索引有如下三只优点:

除此以外,有人因此“三星系统”(three-star
system)来评价一个目录是否切合有查询语句。三星系统要是凭借:如果索引能够用相关的笔录停放一起就是得一星;如果找引中的多少顺序和摸索中的排顺序一致即取得二星;如果找引中的排列包含了询问需要的全套排就收获三星。

目并无连续顶好之家伙,也不是说索引越多越好。总的来说,只要当索引帮助存储引擎快速找到记录带来的便宜大叫那个带的附加工作时,索引才是行之有效之。

对于生小之申,大部分状下简单的全表扫描更高效,没有必要更起目录。对于受到及大型的申,索引带来的裨益就是坏强烈了。

其三、选择说明

  1. 率先选择社区本的GA版(稳定版)。
  2. 选发行时6-10只月以上的GA版。
  3. 慎选最为近几个月没有修复关键BUG的本子,软件工程原理修复了较充分BUG则说明还富含较多之BUG。
  4. 最好向后较长时间没有创新的发行版。
  5. 设想开发人员开发顺序采取的版是否配合选择的版本。
  6. 分选的本子最好是中运转3-6独月,然后于未根本之非核心业务运行3-6单月。
  7. 向DBA大佬请教。

二. 强性能的目录策略

不错地创建同利用索引是兑现大性能查询的根基。前面,已经介绍了各种类型的目录及其利弊,现在来探哪些真正地发表这些索引的优势。下面的几乎独小节将帮大家理解什么迅速地以索引。

季、安装方式

  1. yum安装
  2. 编译安装
  3. 其次进制程序包
  4. rpm安装

2.1 独立的排

咱们平常会看出有的查询不当地采用索引,或者使MySQL无法使用已经有些索引。如果SQL查询语句被之排非是单独的,则MySQL就无见面采用及目。“独立的排”是指索引列不可知是表达式的一样有些,也非能够是函数的参数。

诸如:下面这条SQL查询语句,就无法利用主键索引id:

select id,last_name,first_name,birthday from people where id+1=3;

颇轻看,上面的where表达式其实可以简写为 where
id=2,但是MySQL无法自行分析是表达式。我们理应养成简化where条件的习惯,始终将索引列单独在比运算符的边沿。故使惦记行使到主键索引,正确地写法为:

select id,last_name,first_name,birthday from people where id=2;

下面是另一个科普的缪写法:

select ... from ... where to_days(current_date()) - to_days(date_col) <= 10;

2.2 前缀索引和目录的选择性

有时,我们需要索引很丰富之字符列,这会让索引变得十分且慢。通常的化解智是,只索引列的面前几单字符,这样可大大节省索引空间,从而增强索引的频率。但是,也会见回落索引的选择性。索引的选择性是因,不又的索引值的数额(也叫基数)与数表中的笔录总数的比率,取值范围是0到1。

唯一索引的选择性是1,这是绝好之目录选择性,性能为是太好之。

貌似情形下,某个列前缀的选择性也是够大之,足以满足查询性能。对于Blob、Text或大丰富之Varchar类型的排,必须以前缀索引,即单独针对列的眼前几个字符进行索引,因为MySQL不允许索引这些列的圆长度。

补偿加前缀索引的方法如下:

alter table user add key(address(8)); // 只索引address字段的前8个字符

前方缀索引是千篇一律种植能要索引更粗、更快的卓有成效方式,但缺点是:MySQL无法使用前缀索引做
Order By 和 Group By 操作,也无能为力利用前缀索引做盖扫描。

奇迹,后缀索引(suffix
index)也起用途,例如查找某个域名的富有电子邮件地址。但MySQL原生并无支持后缀索引,我们可把字符串反转后存储,并根据这个建立前缀索引,然后经过触发器来保障这种索引。

2.3 多列索引

差不多列索引是依靠一个索引中包含多个列,必须使留心多单列的逐一。多列索引为让复合索引,如前方的
key(last_name, first_name, birthday) 就是一个复合索引。

一个广大的荒谬就是,为每个列创建单独的目录,或者,按照不当的相继创建了大多列索引。

先来拘禁率先独问题,为每个列创建独立的目,从 show create table
中,很容易见到这种情况:

create table t (
 c1 int,
 c2 int,
 c3 int,
 key(c1),
 key(c2),
 key(c3)
);

这种错误的目录策略,一般是由人们听到有家诸如“把where条件里面的列都加上索引”这样模糊的提议导致的。

以差不多只列上开创独立的单列索引大部分状下并无能够增高MySQL的询问性能。在MySQL
5.0及其后的本子中,引入了一致栽叫索引合并(index
merge)的国策,它以自然水准及足用表上的大半单单列索引来定位指定的推行。但效率要比复合索引差很多。

例如:表 film_actor 在字段 film_id 和 actor_id
上每出一个单列索引,SQL查询语句如下:

select film_id,actor_id from film_actor where actor_id=1 or film_id=1;

于MySQL5.0下的版中,查询能够同时采用就简单单单列索引进行围观,并将结果开展统一。这种算法有三独变种:or条件的协同(union)、and条件的交(intersection)、组合前少栽状况的一起与交。

上面的询问就是采用了少单寻引围观的联合,通过explain中之Extra列(Extra的值备受见面冒出union字符),可以看看这或多或少:

explain select film_id,actor_id from film_actor where actor_id=1 or film_id=1\G

目录合并策略有时候是平栽优化的结果,但骨子里又多上她说明了表上的目建得不可开交不好:

select film_id,actor_id from film_actor where actor_id=1
union all
select film_id,actor_id from film_actor where film_id=1 and actor_id<>1;

设在explain的结果受到,发现了目录的一块,应该可以检查一下SQL查询语句和表的构造,看是免是曾经是极度精良的了,能否拿该拆分为多单查询Union的法等等。

2.4 选择适当的索引列顺序

最容易引起困惑的尽管是复合索引中列的各个。在复合索引中,正确地排列顺序依赖让采用该索引的询问,并且同时要考虑怎样还好地满足排序和分组的待。

索引列的逐一意味着索引首先以最左列进行排序,其次是次排,第三列…。所以,索引可以随升序或者降序进行扫描,以满足精确符合列顺序的order
by、group by和distinct等子句的询问需要。

当不需考虑排序和分组时,将选择性最高的列放到复合索引的极致左边(最前列)通常是雅好的。这时,索引的打算只是用来优化where条件的追寻。但是,可能我们呢得基于那些运行效率高的查询来调整索引列的逐一,让这种场面下索引的选择性最高。

为下面的询问也例:

select * from payment where staff_id=2 and customer_id=500;

举凡应该创建一个 key(staff_id, customer_id) 的目还是 key(customer_id,
staff_id)
的目录?可以跑一些查询来确定表中值的分布状况,并规定谁列的选择性更强。比如:可以就此脚的查询来预测一下:

select sum(staff_id=2), sum(customer_id=500) from payment\G

倘,结果显示:sum(staff_id=2)的值为7000,而sum(customer_id=500)的值也60。由此可知,在方的询问中,customer_id的选择性更强,应该拿其在索引的极其前,也便是运用key(customer_id,
staff_id) 。

唯独,这样做有一个地方得专注,查询的结果非常靠让选定的具体值。如果以上述办法优化,可能对其余不同尺度值的查询不公正,也说不定造成服务器的共同体性能变得又糟糕。

倘若是于pt-query-digest这样的家伙的报着取“最差查询”,再比如上述方式选定的目顺序反复是不行迅速的。假如,没有类似地切实查询来运作,那么最好好还是因经验法则来举行,因为经验法则设想的凡全局基数和选择性,而无是某具体条件值的询问。通过经历法则,判断选择性的主意如下:

select count(distinct staff_id)/count(*) as staff_id_selectivity,
count(distinct customer_id)/count(*) as customer_id_selectivity,
from payment\G

如,结果显示:staff_id_selectivity的值为0.001,而customer_id_selectivity的价值吗0.086。我们理解,值更老,选择性越强。故customer_id的选择性更胜似。因此,还是以那个看做索引列的率先排:

alter table payment add key(customer_id, staff_id);

尽管,关于选择性和全局基数的经验法则值得去研究以及剖析,但必然变化忘了order
by、group by 等要素的熏陶,这些要素可能针对查询的特性造成非常可怜之影响。

2.5 聚簇索引

聚簇索引并无是如出一辙种植单独的索引类型,而是同种多少存储方。具体的细节指让那个实现方式,但InnoDB
的聚簇索引实际上在同等结构面临保留了 B-Tree 索引和数据行。

当表中产生聚簇索引时,它的数据行实际上存放于目录的叶子页(leaf
page)中,也就是说,叶子页含了推行的浑数,而节点页才含有了索引列的数额。

为凡储存引擎负责落实索引,因此并无是持有的储存引擎都支持聚簇索引。本节咱们重点关注InnoDB,这里讨论的情对任何支持聚簇索引的囤引擎都是适用的。

InnoDB 通过主键聚集数据,如果没有定义主键,InnoDB
会选择一个唯一的非空索引代替。如果无这样的目录,InnoDB
会隐式定义一个主键来当聚簇索引。

聚簇索引的长:

设当设计表和查询时,能充分利用上面的独到之处,就可以大幅度地提升性能。

聚簇索引的先天不足:

当InnoDB中,聚簇索引“就是”表,所以不像MyISAM那样需要单独的行存储。聚簇索引的诸一个纸牌节点都带有了主键值、事务ID、用于工作和MVCC(多版本控制)的回滚指针以及有着的剩余列。

InnoDB的二级索引(非聚簇索引)和聚簇索引差别很老,二级索引的纸牌节点受到存储的未是“行指针”,而是主键值。故通过二级索引查找数据经常,会进展有限次寻引查找。存储引擎需要先找找二级索引的叶子节点来赢得相应的主键值,然后根据这个主键值到聚簇索引中搜寻对应的数据行。

为了保证数据行以梯次插入,最简易的法是以主键定义也 auto_increment
自动增长。使用InnoDB时,应该尽可能地照主键顺序插入数据,并且尽量地采取单调增加的主键值来插入新行。

对此高并发工作负荷,在InnoDB中以主键顺序插入可能会见招强烈的主键值什么用的题材。这个题材颇沉痛,可自行百度解决。

2.6 覆盖索引

一般性大家还见面基于查询的where条件来创造合适的目,但迅即才是索引优化的一个点。设计良好之目,应该考虑合查询,而不单单是where条件部分。

目确实是相同种植检索数据的敏捷方式,但是MySQL也得以使用索引来直接获取列的数额,这样尽管不要再夺读取数据行。如果索引的纸牌节点受到已包含了使询问的整整多少,那么,还有什么必要再回表查询也?

若果一个索引包含(或者覆盖)了颇具需要查询的字段(列)的价,我们誉为“覆盖索引”。

蒙面索引是格外有效之,能够极大地提高性能。考虑一下,如果查询才需要扫描索引,而不用回表获取数据行,会带多少利益:

于享有这些场景中,在目录中即完事有查询的资产一般比较更回表查询小得几近。

B-Tree索引可以成为覆盖索引,但哈希索引、空间引得和全文索引等全都未支持挂索引。

当发起一个被索引覆盖的询问(也称索引覆盖查询)时,在 explain 的 Extra
列,可以视 “Using index” 的信。如:

explain select id from people;
explain select last_name from people;
explain select id,first_name from people;
explain select last_name,first_name,birthday from people;
explain select last_name,first_name,birthday from people where last_name='Allen';

people表是我们在上面的小节中创造的,它含一个主键(id)索引和一个大抵列的复合索引key(last_name,
first_name,
birthday),这片个目录覆盖了季单字段的值。如果一个SQL查询语句,要询问的字段都于马上四独字段之中,那么,这个查询就可以让号称索引覆盖查询。如果一个目录包含了某SQL查询语句被具备设询问的字段的值,这个目录对于该查询语句来说,就是一个遮盖索引。例如,key(last_name,
first_name, birthday) 对于 select last_name,first_name from people
就是盖索引。

2.7 使用索引围观来开排序

MySQL有半点种植艺术得以转有序的结果集:通过排序操作(order by)和
按索引顺序扫描的自动排序(即经过搜索引来排序)。其实,这半栽排序操作是未冲突之,也就是说
order by 可以使用索引来排序。

恰地说,MySQL的针对性结果集的排序方式来下两种植:

1、索引排序

目排序是因利用索引中的配段值对结果集进行排序。如果explain出来的type参数的价值吗index,就证明MySQL一定用了目录排序。如:

explain select id from people;
explain select id,last_name from people order by id desc;
explain select last_name from people;
explain select last_name from people order by last_name;
explain select last_name from people order by last_name desc;

在意:就算explain出来的type的价值未是index,也发出或是索引排序。如:

explain select id from people where id >3;
explain select id,last_name from people where id >3 order by id desc;

2、文件排序

文本排序(filesort)是依靠将查询出来的结果集通过额外的操作进行排序,然后回给客户端。这种排序方式,没有使用及目录排序,效率比逊色。虽然文件排序,MySQL将那称为filesort,但并不一定使用磁盘文件。

如果explain出来的Extra参数的价包含“Using
filesort”字符串,就印证是文件排序。此时,你不怕必对索引或SQL查询语句进行优化了。如:

explain select id,last_name,first_name from people where id > 3 order by last_name;

MySQL可以使及一个目既满足查找,又满足查询。如果可能,设计索引时,应该尽量地同时满足这半种操作。

除非当索引的排列包含where条件中的字段和order
by中之字段,且索引中列的顺序和where + order by
中含的持有字段的相继一致(注意:order
by在where的背后)时,才来或以及目录排序。

现行,我们来优化点的那么长SQL语句,使该动索引排序。

率先,添加一个大抵列索引。

alter table people add key(id,last_name);

会发现,仅添加
key(id,last_name),还是没道下索引排序,这是为,where + order by
语句也要满足索引的极端荒唐前方缀要求,而where id >
3是一个克条件,会导致后面的order by
last_name无法用索引key(id,last_name)。

副,将SQL语句被的 order by last_name 改为 order by id,last_name。

留神:如果SQL查询语句是一个干多张表的涉查询,则只有当order
by排序的字段全部源于于第一摆表时,才会以索引排序。

下列有几乎种不克下索引排序的场面:

1、如果order
by根据多独字段排序,但差不多个字段的排序方向无均等,即有字段是asc(升序,默认是升序),有的字段是desc(降序)。如:

explain select * from people where last_name='Allen' order by first_name asc, birthday desc;

2、如果order by包含了一个未以索引列的字段。如:

explain select * from people where last_name='Allen' order by first_name, gender;

3、如果找引列的第一排列是一个限量查找条件。如:

explain select * from people where last_name like 'A%' order by first_name;

4、对于这种情况,可以以SQL语句优化为:

explain select * from people where last_name like 'A%' order by last_name,first_name;

2.8 冗余和重索引

MySQL允许在同等的列上创建多只目录(只不过索引的名号不同),由于MySQL需要独自维护还的目,并且优化器在优化查询时为用各个个地开展辨析考虑,故再次的索引会影响属性。

再次索引是依在同等的列上按照同样之排顺序创建的门类相同之目。应该避免创建重复索引,发现以后呢答应即时去。

冗余索引和再次索引不同。如果创建了寻找引 key(A, B),再来创造索引
key(A),就是冗余索引。因为索引(A)只是前面一个目录的前头缀索引。索引(A,
B)也可看做索引(A)来运。但是,如果还创索引(B,A),就非是冗余索引了。

冗余索引通常有在啊表添加新索引的时刻。例如,有人或许会见增加一个新的目录(A,
B),而不是扩张已部分索引(A)。还有一样种情形是,将一个二级索引(A)扩展为(A,
ID),其中ID是主键,对于InnoDB来说,二级索引中曾经默认包含了主键列,所以这吗是冗余的。

大部状态下,都未待冗余索引。应该尽可能扩大已有的索引而非是开创新索引。但有时,出于性能方面的设想,也需冗余索引,因为扩展已有的索引会导致其更换充分,从而会潜移默化其它以该索引的查询语句的属性。

以扩展索引的下,需要特地小心。因为二级索引的纸牌节点包含了主键值,所以当列(A)上的目录就相当给当(A,
ID)上的目录。如果有人据此了像 where A=5 order by ID
这样的询问,索引(A)就特别管用。但是,如果您用引得(A)修改也索引(A,
B),则实在即便改成了目录(A, B, ID),那么,上面查询的order
by语句就无法使用索引排序,而不得不采用文件排序了。

推介以Percona工具箱中的pt-upgrade工具来仔细检查计划着之索引变更。

故,只有当你针对一个目相关的拥有查询都颇懂时,才去扩大原有的目。否则,创建一个初的目录(让老索引成为新索引的冗余索引)才是太保险的主意。

2.9 未使用的目

MySQL服务器中或会见生出一部分世代都未会见因此到的目录,这样的目录完全是繁琐,建议考虑去。但万一注意的凡,唯一索引的唯一性约束效力,可能有唯一索引一直无叫询问利用,却能够用于避免起更的数目。

http://www.bkjia.com/Mysql/1298254.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/1298254.htmlTechArticleMySQL的索引详解,MySQL索引详解 一. 索引基础 1.1
简介
在MySQL中,索引(index)也称“键(key)”,它是储存引擎用于快速找到记录之平等种…

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图