精华内容
下载资源
问答
  • 转:https://juejin.im/post/6844904073955639304添加链接描述

    转:https://juejin.im/post/6844904073955639304添加链接描述

    展开全文
  • Mysql索引底层原理

    2020-07-19 00:03:05
    索引分为:单列索引和组合索引 单列索引,即一个索引只包含单个列,一个表可以有多个单列索引,但这不是组合索引组合索引,即一个索引包含多个列。 实际上,索引也是一张表,该表保存了主键与索引字段,并指向...

    索引的本质:

    什么是索引
    mysql官方定义,索引是帮助Mysql高效获取数据的排好序的快速查找的数据结构
    即索引可以大大提高MySQL的检索速度 。

    索引的优势

    1,通过索引可以提高数据的检索效率,降低数据库的IO成本
    2,通过索引列对数据进行排序,降低数据排序的成本,降低了CPU的消耗

    索引的劣势

    1, 实际上,索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录,因此建立索引会占用磁盘空间
    2,虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件。每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息。
    3,索引只是调高效率的一个因素,如果你的mysql有大量的表,就需要花时间研究建立最优秀的索引,或优化查询。

    索引的分类

    单值索引:即一个索引只包含单个列,一个表可以有多个单列索引(但这种情况可不是复合索引)。
    唯一索引:索引列的值必须唯一,但允许有空值。
    复合索引:即一个索引包含多个列。

    基本语法
    column写一个就是单值索引,写多个就是复合索引。带UNIQUE就是唯一索引
    创建:CREATE [UNIQUE] INDEX indexName ON tableName(columnName(length));
    ALTER tableName ADD [UNIQUE] INDEX [indexName] ON (columnName(length));
    删除:DROP INDEX [indexName] ON tableName;
    查看:SHOW INDEX FROM tableName;
    只用ALTER命令
    在这里插入图片描述

    索引的数据结构

    二叉树
    红黑树
    Hash表
    B-Tree
    == 二叉树–>红黑树–>B树–>B+树(不断改进的过程)==

    二叉树:即二叉查找树:左节点小于父节点,右节点大于父节点。
    红黑树: 是一种自平衡二叉查找树,就是特化的平衡二叉树,就是在进行插入和删除操作时通过特定操作保持二叉查找树的平衡,从而获得较高的查找性能,但它的左右子树高差有可能大于 1,所以红黑树不是严格意义上的平衡二叉树。它虽然是复杂的,但它的最坏情况运行时间也是非常良好的,并且在实践中是高效的: 它可以在O(log n)时间内做查找,插入和删除。
    性质1. 节点是红色或黑色。
    性质2. 根节点是黑色。
    性质3.所有叶子都是黑色。(叶子是NULL节点)
    性质4. 每个红色节点的两个子节点都是黑色。(从每个叶子到根的所有路径上不能有两个连续的红色节点)
    性质5… 从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。
    == 这些约束强制了红黑树的关键性质: 从根到叶子的最长的可能路径不多于最短的可能路径的两倍长。*==

    BTree(多路搜索树)
    在这里插入图片描述

    B+树(多路平衡查找树)
    每个节点横向上存储多个索引元素
    叶节点存储所有的索引和数据
    在这里插入图片描述

    Mysql具体是怎么运用B+树来存储索引呢?

    存储引擎:Myisam和InnoDB
    存储引擎是形容表级别的,所以每张表的存储引擎可能不同。
    在这里插入图片描述
    MyISAM引擎 索引文件和数据文件是分离的(非聚集)
    .frm是表结构文件
    .MYD存放的是表数据
    .MYI存放表索引

    InnoDB引擎 (聚集):
    表数据文件本身就是按B+Tree组织的一个索引结构文件
    聚集索引-叶节点包含了完整的数据记录(索引值+数据)
    为什么InnoDB表必须有主键,并且推荐整型的自增主键?
    为什么非主键索引结构叶子节点存储的是主键值?(一致性和节省存储空间)
    .frm存放表结构
    .idb存放表的索引和数据

    MyISAM存储引擎索引实现
    假设执行一个查询语句: select * from table where Col1=49;
    1,首先先去MYI文件找到索引49(MYI文件里索引的组织形式就是B+树)
    2,然后根据找到的data地址直接去MYD文件定位到相应数据
    在这里插入图片描述
    InnoDB存储引擎索引实现:

    在这里插入图片描述
    再来说说,为什么InnoDB表必须有主键,并且推荐整型的自增主键?
    因为mysql表数据文件本身就是按B+Tree组织的一个索引结构文件,它要求你必须要有主键,如果没有主键这个表数据是没办法组织的。
    (那么有同学就会说哥们你这么说我就不同意了,我之前建了InnoDB的表就没设置主键也建成功了啊!)
    那是为什么我告诉你,你没有设主键并不代表它没有主键,在mysql你建了一张表没有设主键,它会选择你可以唯一标识一条记录的那一列自动为你建一个主键,如果没有唯一标识的那一列,它会在表里面默认给你加一列,由它来帮你维护这唯一的主键索引,你是看不到的。== 说白了它必须要有这么一列主键,来帮你组织整张表的数据。所以InnoDB必须要有主键,因为它设计如此。==
    为什么推荐使用整型自增主键,而不是像UUID这样的字符串,因为它在B+树上查找索引时,要不断地进行比较,那么你认为是比较整型数快还是字符串快?更何况整型数也比较节省空间。
    为什么推荐自增?
    因为B+树所有叶节点都会通过指针串起来的,从下图可以看出B+树的一个特性:它每个节点内部都是按照递增的顺序维护的,每个节点间也是按照从左到右递增的顺序维护的。 这就是B+树的一个特性== 每个节点都是按照从左到右递增的顺序来存储。==
    在这里插入图片描述
    再来说,mysql表的所有方法并不一定非要按照B+树来,例如上述所说的它可以有很多种,Hash结构就是其一。Hash结构大概就是这么回事:
    它将索引和数据用Hash表来存储,即为每个索引建立唯一的hash值放在hash表里,对应后面跟其数据。
    比方说,我们 select from table where Col1=20;
    它会首先做一个hash运算 hash(20)=(唯一的散列值)即hash值,然后拿这个hash值去hash表里直接定位到相应的数据。
    (估计有同学又会说了,这hash索引好像更牛逼一点啊,只进行了一次hash运行就能迅速定位到数据,而且hash运算又是非常快的)
    但是,工作中99.9%以上情况都是用B+树,而不是hash。虽然感觉hash定位的效率更高。为什么?
    假如这样,select * from table where Col1>20;查找大于20 的记录。hash只能定位确定的索引,是不是对范围查找hash就没辙了。这就是hash查找的缺点,对范围查找支持的非常差。
    == 而B+树就很好的支撑范围查找了,因为B+树叶节点之间有指针,又要求了索引是自增的,所以查找大于20 的记录的时候,找到值为20的索引,接着就简单了,直接顺藤摸瓜把20 之后的节点全部拿出来就好了。==
    B树呢?由于B树叶节点是没有指针把它们穿起来的,所以当B树进行范围查找时,不能进行节点间的访问,访问到20后,要返回到父节点,从父节点向下再去访问相邻节点49,依次进行返回访问返回访问…
    在这里插入图片描述
    所以是不是觉得还是B+树更牛逼些!

    哪些情况需要创建索引呢?

    1,主键自动建立唯一索引
    2,频繁作为查询条件的字段应该创建索引
    3,查询中与其它关联的字段,外键关系建立索引
    4,频繁更新的字段不适合创建索引
    5, where条件里用不到的字段不创建索引
    6,单键/组合索引的选择问题,who?(在高并发下创建组合索引)
    7,查询中排序的字段,排序字段若通过索引去访问将大大提高排序速度。
    8,查询中统计或者分组字段

    哪些情况不要创建索引呢?

    1,表记录太少
    2,经常增删改的表
    3,如果某个数据列包含许多重复的内容,为它建立索引就没有太大实际效果

    性能分析

    Explain
    是什么?
    在这里插入图片描述
    能干嘛?
    在这里插入图片描述

    怎么用?
    explain select * from table;
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    一般来说,得保证查询至少到达range级别,最好能到达ref。
    说说这些类型都是什么意思
    在这里插入图片描述

    展开全文
  • MySQL索引底层原理

    2019-11-24 14:22:22
    文章目录什么是索引索引的类型从逻辑角度进行分类从物理角度进行分类从数据结构角度进行分类为什么InnoDB默认选用B+作为数据的存储结构主键索引的数据结构联合索引的数据结构主键索引的data数据为什么全在叶子节点上...

    什么是索引

    • 索引时帮助我们高校获取数据的排好序的数据结构

    • 索引它是一个文件

    • 走索引的本质是在索引B+树中从上到下根据索引指向的叶子节点进行扫描

    索引的类型

    从逻辑角度进行分类

    • 主键索引

    ALTER TABLE table_name ADD PRIMARY KEY ( column )

    顾名思义,它是一张表中主键的一种唯一性索引

    • 唯一索引

    ALTER TABLE table_name ADD UNIQUE ( column )

    索引中的值只能够是唯一的,如果新增/修改的索引数据不是唯一的,那么将会报错

    • 普通索引

    ALTER TABLE table_name ADD INDEX index_name ( column )

    或者联合索引

    ALTER TABLE table_name ADD INDEX index_name ( column1, column2, column3 )

    基本的索引类型,不对唯一性约束

    • 全文索引

    ALTER TABLE table_name ADD FULLTEXT ( column)

    从物理角度进行分类

    数据存储在磁盘中

    InnoDB引擎
    使用InnoDB作为表的存储引擎时,会生成两个文件:
    .frm结尾的文件:用来存储表的结构定义;
    .ibd结尾的文件:用来存储索引结构数据和元素数据

    MyISAM引擎
    使用MyISAM作为表的存储引擎时,会生成三个文件:
    .frm结尾的文件:用来存储表的结构定义;
    .MYD结尾的文件:用来存储表中一行一行的数据;
    .MYI结尾的文件:用来存储表中定义的索引;
    它不支持事务,每次查找数据都要经过两个数据文件的交互

    • 聚集索引

    主键索引的叶子节点包含完整的数据记录
    叶子节点data区域存储的是元素数据

    • 非聚集索引

    索引的叶子节点不包含完整的数据记录,每次查找数据都要经过两个数据文件的交互
    叶子节点data区域存储的不是元素数据,而是该元素在磁盘文件中的磁盘指针

    从数据结构角度进行分类

    • B+树索引

    1、元素数据都存在叶子节点中,非叶子节点只存储索引

    2、关键的索引数据在非叶子节点上做了冗余,完整的数据存储在叶子节点上

    3、前一个叶子节点指向后一个叶子节点

    4、一个节点存储更多的数据,能够很好的控制数的高度

    • hash索引

    对主键进行求hash值,求出的hash值对数据的地址值有映射关系,就能够找到该数据,仅支持精准查找。但是范围查找需要全表扫描效率很慢,范围查找很少的情况下可以考虑使用hash表

    为什么InnoDB默认选用B+树作为数据的存储结构

    • hash:

    对主键进行求hash值,求出的hash值对数据的地址值有映射关系,就能够找到该数据,仅支持精准查找。但是范围查找需要全表扫描效率很慢,范围查找很少的情况下可以考虑使用hash表

    • 二叉查找树(AVL树):

    1、左子树的元素小于父元素,右子树的元素大于父元素

    2、随着数据的增加,树的高度不可控,当元素越多时,树的高度会很大,这样相对于磁盘的IO次数也会很大

    3、当主键id为自增的时候,二叉树表现为一个链表(链表是特殊的平衡二叉树),走索引查找数据时相当于全表扫描

    4、AVL(平衡二叉树)增加一个元素,树的深度有可能会+1,相对于磁盘IO +1

    • 红黑树:

    相比于AVL树,在增加数据时,会通过左旋右旋优化树的高度,在树的高度上有了优化,但是红黑树的高度还是不可控的

    • B树:

    1、相比于AVL树,B树的一个节点能存储多个元素,一个节点中的元素从左到右还是递增的

    2、每个节点都有指针指向子节点,叶子节点的指针为空

    3、B树每个节点都能存储元素

    • B+树:

    1、degree:定义每个节点中数据的个数

    2、元素数据都存在叶子节点中,非叶子节点只存储索引

    3、关键的索引数据在非叶子节点上做了冗余,完整的数据存储在叶子节点上

    4、前一个叶子节点指向后一个叶子节点

    5、一个节点存储更多的数据,能够很好的控制数的高度

    主键索引的数据结构

    create table if not exists innodb_test(
    	id int not null auto_increment,
    	name varchar(10),
    	age int,
    	sex varchar(10),
    	primary key(id)
    )engine=innodb default charset=utf8mb4;	
    
    insert into innodb_test(id,name,age,sex) values(21,'d',19,'男');
    insert into innodb_test(id,name,age,sex) values(25,'h',25,'男');
    insert into innodb_test(id,name,age,sex) values(30,'b',25,'女');
    insert into innodb_test(id,name,age,sex) values(34,'c',24,'女');
    insert into innodb_test(id,name,age,sex) values(15,'a',20,'女');
    insert into innodb_test(id,name,age,sex) values(18,'e',20,'女');
    insert into innodb_test(id,name,age,sex) values(20,'f',21,'男');
    insert into innodb_test(id,name,age,sex) values(35,'x',30,'男');
    insert into innodb_test(id,name,age,sex) values(49,'y',27,'女');
    

    这个表它只有id的主键索引

    在这里插入图片描述

    联合索引的数据结构

    create table if not exists innodb_test(
    	id int not null auto_increment,
    	name varchar(10),
    	age int,
    	sex varchar(10),
    	primary key(id),
    	KEY `idx_innodb_test_name_age` (name,age)
    )engine=innodb default charset=utf8mb4;	
    
    insert into innodb_test(id,name,age,sex) values(21,'d',19,'男');
    insert into innodb_test(id,name,age,sex) values(25,'h',25,'男');
    insert into innodb_test(id,name,age,sex) values(30,'b',25,'女');
    insert into innodb_test(id,name,age,sex) values(34,'c',24,'女');
    insert into innodb_test(id,name,age,sex) values(15,'a',20,'女');
    insert into innodb_test(id,name,age,sex) values(18,'e',20,'女');
    insert into innodb_test(id,name,age,sex) values(20,'f',21,'男');
    insert into innodb_test(id,name,age,sex) values(35,'x',30,'男');
    insert into innodb_test(id,name,age,sex) values(49,'y',27,'女');
    

    这个表它有id的主键索引,还有name和age字段组成的联合索引

    在这里插入图片描述

    主键索引的data数据为什么全在叶子节点上?

    因为一个节点大小固定的情况下,如果不存data数据,那么将能存储更多的索引元素,那么该节点的子节点也会更多,从而整个B+树的深度也会更少,最后与磁盘的IO次数也会更少。

    MySQL默认设置1个节点为1页的大小为16kb

    1、当选用bigint类型作为主键时,占用8个字节即8B,指针的大小为6个字节即6B。那么一个节点能大约储存(16*1024-8)/(8+6)=1169个元素

    2、树的第二层也是存储索引元素时,第三层当一个data元素的大小约为1K时,最终一个三层的B+树能储存11691169(16/1)=2186万个数据

    3、也就是说3次磁盘IO的情况下就能够储存2186万个叶子节点元素

    什么是聚集索引和非聚集索引

    数据存储在磁盘中

    InnoDB:使用MyISAM作为表的存储引擎时,会生成两个文件:
    .frm结尾的文件:用来存储表的结构定义
    .ibd结尾的文件:用来存储索引结构数据和元素数据
    MyISAM:使用MyISAM作为表的存储引擎时,会生成三个文件:
    .frm结尾的文件:用来存储表的结构定义
    .MYD结尾的文件:用来存储表中一行一行的数据
    .MYI结尾的文件:用来存储表中定义的索引
    它不支持事务,每次查找数据都要经过两个数据文件的交互

    非聚集索引
    索引的叶子节点不包含完整的数据记录,每次查找数据都要经过两个数据文件的交互
    叶子节点data区域存储的不是元素数据,而是该元素在磁盘文件中的磁盘指针

    聚集索引
    主键索引的叶子节点包含完整的数据记录
    叶子节点data区域存储的是元素数据

    为什么建议使用InnoDB引擎的表使用整型的自增主键而不是UUID?

    1、使用InnoDB引擎的表的数据都存储在主键索引中的B+树中。如果建表时没有指定主键,那么MySQL会为我们生成一个隐藏的主键用来维护表的数据并存储元素(因为元素数据都存储在主键索引B+树中的叶子节点中),但是在查询的时候并不能查询出来,同时隐藏的主键也占用了磁盘空间

    2、使用InnoDB引擎的表的数据在插入的时候,会使用主键对元素进行排序,最终插入到主键索引B+树中的叶子节点根据主键递增。如果主键不是整型的,那么MySQL需要花费时间在对主键元素进行字符转换;如果主键不是自增的,MySQL在插入元素时需要对插入的逐渐进行插入排序,数据在插入时有可能还需要对节点进行分裂,然后再平衡,从而浪费性能;如果主键时整型的自增的,那么MySQL直接在最后面添加元素,从而提高了插入元素的效率。自增的主键索引它会尽可能的避免数据插入到叶子节点中时对叶子节点产生分裂然后再平衡

    3、UUID字符串长,并没有实际的意义,占用的内存空间大,字符无序。在新增数据时,由于需要对主键进行排序,当主键为UUID时,需要进行很复杂的排序,浪费性能,而且当数据需要的空间超出了节点所能存储的大小时,数据在插入时有还需要对节点进行分裂,然后再B+树平衡。使用自增的主键作为主键时,直接走索引确定新增的数据在叶子节点最右侧新增即可

    为什么非主键索引的叶子节点中data数据存储的是主键值?

    1、如果在非主键索引的叶子节点中存储完整的数据,那么叶子节点内存储的元素数量更少了,可能会造成需要更多的磁盘IO,需占用更多的内存

    2、在修改表数据时,需要同时修改主键索引和非主键索引中的数据,那么就存在数据一致性的问题,在高并发的情况下,数据会出现数据不一致的情况

    什么是最左前缀原则

    使用联合索引时需要遵守最左前缀原则

    最左前缀原则:
    KEY idx_innodb_test_name_age_sex (name,age,sex)为例,当where条件中为name时,或者为name和age,或者为name、age、sex才能使用索引,并且从左至右查找时,遇到范围、模糊查询(>、<、between、like)就会停止继续向右匹配索引中的数据

    因为索引在一个节点上储存是按照索引字段的顺序进行储存的,只能先比较前一个字段才能比较后一个字段

    为什么like模糊查询时,%在前不能使用索引而是走全表扫描

    %在前,不能匹配到索引,因为匹配索引需要从左至右匹配,最左边为%,不能确定具体字符,不能匹配索引。like ‘name%’,就能使用索引,因为,‘name%最左边为准确的字符,可以与索引进行匹配’

    为什么不建议在where条件中进行运算

    举例:select * from t1 where age + 1 = 21将不能使用索引需走全表扫描,因为在where条件中进行运算,MySQL将是需要重新建一颗age + 1的索引B+树,这样的效率更低,可能SQL执行优化器会觉得使用全表扫描是一条最短路径

    MySQL索引的一些总结

    • 数据库中的数据是存储在磁盘中的,每一次从磁盘中取数据到内存,叫做一次磁盘IO

    • 建立索引就是对数据进行排序,排序就是比较大小,B+树其实就是帮助我们排序的一种数据结构

    • insert在插入数据的时候就会对主键ID进行升序排序

    • B+树一个节点可以储存多个元素

    • 非叶子节点都会冗余一份在叶子节点,叶子节点存储了所有的元素;叶子节点之间用双向指针进行连接

    • 当新建的表中没有设置主键,那么会先看是否有唯一索引,如果没有,会生成一个隐藏的自增的id,select不能够查询出来,所以说使用InnoDB引擎的表一定会有一个主键id

    • where条件能否利用索引本质上就是看此条件能不能和某个B+树索引进行比较大小从而查询数据

    • 最左前缀原则:本质就是对多个字段联合组成的复合字段进行比较大小,类似字符串比较大小,只有给定了最左侧的字段,才能去比较后续的字段

    • 全表扫描:在InnoDB中,表中所用行数据都在主键索引的叶子节点中,所以全表扫描就是直接扫描主键索引的叶子节点

    • 覆盖索引:对于某一个SQL在执行时,如果发现所要查询的数据在某一个索引上也存在时(除开主键索引),那么就可以直接利用这个索引进行查询获取数据,而不需要回表

    • 在MySQL中,数字与字符串进行运算时,统一会将字符串转换成数字,非数字字符串会统一转化为0

    • InnoDB引擎中:innodb_page_size页,1页=16kb=16384字节,这个值可以进行修改,但是一般不进行修改,查询1页的大小命令:
      show global status like 'innodb_page_size'show variables like ‘innodb_page_size’`

    • 并不是满足了走索引的条件就一定会走索引

    当a为主键,b、c、d的联合索引
    select * from t1 where b > 1可能就不会走索引,因为一条SQL在执行的过程中需要经过MySQL的SQL执行优化器的选择优化,它可能认为在数据量少的情况下直接就走全表扫描是一条最短路径,而使用(b,c,d)的联合索引还需要进行回表操作,更浪费性能和时间

    • 回表

    除主键索引外的B+树并没有存储完整的主键,除了索引数据外只存在主键,获取除索引数据和主键数据之外的数据需要通过回表操作通过主键再去主键的B+树中查询数据其他数据

    展开全文
  • mysql索引底层原理分析

    万次阅读 多人点赞 2018-09-23 00:01:40
    大家都知道索引的重要性,基本用法在上章《最全面的mysql索引知识大盘点》已分享过,本章主要是探索索引底层实现原理。当然了,我们还是以mysql为基准进行探讨。 目录 前言:innodb和myisam的区别 1.物理磁盘...

    大家都知道索引的重要性,基本用法在上章《最全面的mysql索引知识大盘点》已分享过,本章主要是探索索引的底层实现原理。当然了,我们还是以mysql为基准进行探讨。

    目录

    前言:innodb和myisam的区别

    1.物理磁盘知识

    1.1基本概念

    1.2硬盘中的数据

    1.3磁盘的读写原理

    1.5磁盘的读取响应时间

    1.6 I/O 的预读与局部性原理

    2.推理并拆解普通查询语句

    3.为什么要用B+Tree实现

    3.1 B-Tree

    3.2 B+Tree

    3.3 B-树和B+树的区别

    3.4 MongoDB 为什么使用B-树

    4.Mysql索引是如何实现的

    4.1 InnoDB 中的 B+Tree

    4.2 Myisam 中的 B+Tree


    前言:innodb和myisam的区别

     

    InnoDB

    MyISAM

    简介

    由Innobase Oy公司开发。

    支持事务安全的引擎,支持外键、行锁、事务是他的最大特点。如果有大量的update和insert,建议使用InnoDB,特别是针对多个并发和QPS较高的情况。

    默认表类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写,它是存储记录和文件的标准方法。不是事务安全的,而且不支持外键,如果执行大量的select,insert MyISAM比较适合。

    使用场景

    在线事务处理(OLTP)型应用

    在线分析处理(OLAP) 型应用

    锁差异

    Innodb支持事务和行级锁,是innodb的最大特色。

    事务的ACID属性,并发事务带来的几个问题:更新丢失,脏读,不可重复读,幻读。

    事务隔离级别:未提交读(Read uncommitted),已提交读(Read committed),可重复读(Repeatable read),可序列化(Serializable)

    myisam只支持表级锁,用户在操作myisam表时,select,update,delete,insert语句都会给表自动加锁,如果加锁以后的表满足insert并发的情况下,可以在表的尾部插入新的数据。也可以通过lock table命令来锁表,这样操作主要是可以模仿事务,但是消耗非常大,一般只在实验演示中使用。

    数据库文件差异

    innodb属于索引组织表

    innodb有两种存储方式,共享表空间存储和多表空间存储

    两种存储方式的表结构和myisam一样,以表名开头,扩展名是.frm。

    如果使用共享表空间,那么所有表的数据文件和索引文件都保存在一个表空间里,一个表空间可以有多个文件,通过innodb_data_file_path和innodb_data_home_dir参数设置共享表空间的位置和名字,一般共享表空间的名字叫ibdata1-n。

    如果使用多表空间,那么每个表都有一个表空间文件用于存储每个表的数据和索引,文件名以表名开头,以.ibd为扩展名。

    myisam属于堆表

    myisam在磁盘存储上有三个文件,每个文件名以表名开头,扩展名指出文件类型。

    .frm 用于存储表的定义

    .MYD 用于存放数据

    .MYI 用于存放表索引

    myisam表还支持三种不同的存储格式:

    静态表(默认,但是注意数据末尾不能有空格,会被去掉)

    动态表

    压缩表

    索引差异

    1、关于自动增长
    myisam引擎的自动增长列必须是索引,如果是组合索引,自动增长可以不是第一列,他可以根据前面几列进行排序后递增。
    innodb引擎的自动增长列必须是索引,如果是组合索引也必须是组合索引的第一列。
    2、关于主键
    myisam允许没有任何索引和主键的表存在,
    myisam的索引都是保存行的地址。
    innodb引擎如果没有设定主键或者非空唯一索引,就会自动生成一个6字节的主键(用户不可见)
    innodb的数据是主索引的一部分,附加索引保存的是主索引的值。
    3、关于count()函数
    myisam保存有表的总行数,如果select count(*) from table;会直接取出出该值
    innodb没有保存表的总行数,如果使用select count(*) from table;就会遍历整个表,消耗相当大,但是在加了wehre       条件后,myisam和innodb处理的方式都一样。
    4、全文索引
    myisam支持 FULLTEXT类型的全文索引
    innodb不支持FULLTEXT类型的全文索引,但是innodb可以使用sphinx插件支持全文索引,并且效果更好。(sphinx   是一个开源软件,提供多种语言的API接口,可以优化mysql的各种查询)
    5、delete from table
    使用这条命令时,innodb不会从新建立表,而是一条一条的删除数据,在innodb上如果要清空保存有大量数据的表,最       好不要使用这个命令。(推荐使用truncate table,不过需要用户有drop此表的权限)

    6、索引保存位置
    myisam的索引以表名+.MYI文件分别保存。
    innodb的索引和数据一起保存在表空间里

    InnoDB有两类索引,聚集索引(Clustered Index)与普通索引(Secondary Index):

    • InnoDB的每一个表都会有聚集索引
    • 如果表没有定义PK,则第一个非空unique列是聚集索引,否则,InnoDB会创建一个隐藏的row-id作为聚集索引
    • InnoDB的普通索引,实际上会扫描两遍:第一遍,由普通索引找到PK,第二遍,由PK找到行记录

    聚集索引

    数据文件本身就是索引文件,非叶子节点存放<key,address>,address就是下一层的地址,通过PK可以直接定位到数据地址

    非聚簇索引

    叶子节点上的data是主键(即聚簇索引的主键),而不是记录所在地址,因为记录所在地址并不能保证一定不会变,但主键可以保证。定位流程第一步,由普通索引找到PK,第二步,由PK找到行记录

    1.物理磁盘知识

    首先dbms本身就是一个文件管理系统,只是它的实现方式确实比较复杂,但本质上是要通过访问磁盘才能完成数据的存储与检索。本着刨根问底的精神,就要分析文件是存储及检索的。

    1.1基本概念

    盘片

    1. 硬盘中一般会有多个盘片组成,盘片一般用铝合金材料做基片
    2. 硬盘的盘片组在 2-14 片不等,通常有 2-3 个盘片

    盘面

    1. 一个盘片都有上下两个盘面,一般每个盘面都会得到利用,都可以存储数据,成为有效盘面,也有极个别的硬盘盘面数为单数,
    2. 每一个有效盘面都有一个盘面号,按顺序从上至下从 0 开始编号

    磁头

    1. 每一个有效盘面都有一个对应的读写磁头,作用就是将存储在硬盘盘片上的磁信息转化为电信号向外传输
    2. 工作原理则是利用特殊材料的电阻值会随着磁场变化的原理来读写盘片上的数据。磁头是用线圈缠绕在磁芯上制成的。硬盘在工作时,磁头通过感应旋转的盘片上磁场的变化来读取数据通过改变盘片上的磁场来写入数据。为避免磁头和盘片的磨损,在工作状态时,磁头悬浮在高速转动的盘片上方,而不与盘片直接接触,只有在电源关闭之后,磁头会自动回到在盘片上的固定位置(称为着陆区,此处盘片并不存储数据,是盘片的起始位置)。

    磁道

    1. 磁盘在格式化时盘面被划分成许多同心圆,这些同心圆轨迹叫做磁道,而磁带的磁道是沿磁带长度方向的直线,这些磁道用肉眼是根本看不到的。
    2. 磁道从外向内0开始顺序编号,每一个盘面有 300-1024 个磁道,新式大容量硬盘每面的磁道数更多,信息以脉冲串的形式记录在这些轨迹中,这些同心圆不是连续记录数据,而是被划分成一段段的圆弧。
    3. 当磁盘旋转时,磁头若保持在一个位置上,则每个磁头都会在磁盘表面划出一个圆形轨迹,这些圆形轨迹就叫做磁道

    柱面

    1. 所有盘面上的同一磁道(具有相同编号磁道)构成一个圆柱,通常称作柱面。
    2. 每个圆柱上的磁头由上而下从 0 开始编号,数据的读 / 写按柱面进行,只有在同一柱面所有的磁头全部读 / 写完毕后磁头才转移到下一柱面。
    3. 选取磁头只需要通过电子切换即可,而选取柱面则必须机械切换,电子切换相当快。

    扇区

    1. 每个磁道被等分为若干个弧段,这些弧段便是硬盘的扇区,扇区是硬盘的最小读写单元
    2. 操作系统以扇区形式将信息存储在硬盘上,每个扇区包括512个字节的数据和一些其他信息,一个扇区有两个主要部分:存储数据地点的标识符和存储数据的数据段

    标识符就是扇区头标,包括组成扇区三维地址的三个数字:盘面号,柱面号,扇区号(块号)。

    数据段可分为数据和保护数据的纠错码(ECC)。

    磁盘块/簇

    1. 虚拟出来的,块是操作系统中最小的逻辑存储单位,操作系统与磁盘打交道的最小单位是磁盘块。通俗的来讲,在Windows下如NTFS等文件系统中叫做簇;在Linux下如Ext4等文件系统中叫做块(block)。每个簇或者块可以包括2、4、8、16、32、64…2的n次方个扇区
    2. 读取方便:由于扇区的数量比较小,数目众多在寻址时比较困难,所以操作系统就将相邻的扇区组合在一起,形成一个块,再对块进行整体的操作。
    3. 分离对底层的依赖:操作系统忽略对底层物理存储结构的设计。通过虚拟出来磁盘块的概念,在系统中认为块是最小的单位。

    Page

    1. 操作系统经常与内存打交道的最小单位是页,类似于“块”的概念,都需要一种虚拟的基本单位。

    磁盘容量计算

    存储容量 = 磁头数 × 磁道(柱面)数 × 每道扇区数 × 每扇区字节数

    某磁盘是一个 3个圆盘6个磁头,7个柱面(每个盘片7个磁道) 的磁盘,每条磁道有12个扇区,所以此磁盘的容量为:6 * 7 * 12 * 512 = 258048

    1.2硬盘中的数据

    信息存储在硬盘里,硬盘是由很多的盘片组成,通过盘片表面的磁性物质来存储数据。
    把盘片放在显微镜下放大,可以看到盘片表面是凹凸不平的,凸起的地方被磁化,代表数字 1,凹的地方没有被磁化,代表数字 0,因此硬盘可以通过二进制的形式来存储表示文字、图片等的信息。
    所有的盘片都固定在一个旋转轴上,这个轴即盘片主轴,所有的盘片之间是绝对平行的,在每个盘片的盘面上都有一个磁头,磁头与盘片之间的距离比头发丝的直径还小。
    所有的磁头连在一个磁头控制器上,由磁头控制器负责各个磁头的运动,磁头可沿盘片的半径方向移动,实际上是斜切运动,每个磁头同一时刻必须是同轴的,即从正上方往下看,所有磁头任何时候都是重叠的。
    由于技术的发展,目前已经有多磁头独立技术了,在此不考虑此种情况。
    盘片以每分钟数千转到上万转的速度在高速运转,这样磁头就能对盘片上的指定位置进行数据的读写操作。
    由于硬盘是高精密设备,尘埃是其大敌,所以必须完全密封。

    1.3磁盘的读写原理

    系统将文件存储到磁盘上时,按柱面、磁头、扇区的方式进行,即最先是第1磁道的第一磁头下的所有扇区,然后是同一柱面的下一个磁头……
    一个柱面存储满后就推进到下一个柱面,直到把文件内容全部写入磁盘。
    系统也以相同的顺序读出数据,读出数据时通过告诉磁盘控制器要读出扇区所在柱面号、磁头号和扇区号(物理地址的三个组成部分)进行。

    注:操作系统读取同理,只是颗粒的更大的块操作

    1.5磁盘的读取响应时间

            当需要从磁盘读取数据的时候,系统会将数据的逻辑地址传递个磁盘,磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址,即确定要读的数据在哪个磁道,哪个扇区。

            首先必须找到柱面,即磁头需要移动对准相应磁道,这个过程叫做寻道。

            然后目标扇区旋转到磁头下,即磁盘旋转将目标扇区旋转到磁头下。

           寻道(时间):磁头移动定位到指定磁道所需要的时间,寻道时间越短,I/O操作越快,目前磁盘的平均寻道时间一般在3-15ms,一般都在10ms左右。

            旋转延迟(时间):盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间,旋转延迟取决于磁盘转速。普通硬盘一般都是7200rpm,慢的5400rpm。

            数据传输(时间):数据在磁盘与内存之间的实际传输所需要的时间。

    1. 确定磁盘地址(柱面号,磁头号,扇区号),内存地址(源/目):
    2. 为了读取这个扇区的数据,需要将磁头放到这个扇区上方,为了实现这一点:
    3. 即一次访盘请求(读 / 写)完成过程由三个动作组成:

    注:读写一次磁盘信息所需的时间中软件应着重考虑减少寻道时间和延迟时间。

    1.6 I/O 的预读与局部性原理

    由于存储介质的特性,磁盘本身存取就比主存慢很多,再加上机械运动耗费的时间,磁盘的存取速度往往是主存的几百分之一。

    因此,计算机科学中著名的局部性原理:

    1. 当一个数据被用到时,其附近的数据一般来说也会被马上使用。

    2. 程序运行期间所需要的数据通常比较集中。

    3. 由于磁盘顺序读取的效率很高(不需要寻道时间,只需要很少的旋转时间),因此对于具有局部性的程序来说,预读可以提高 I/O 效率。

    预读的长度一般为页(在许多操作系统中,页的大小通常为 4k)的整数倍。操作系统以内存页为单位管理内存,内存页的大小对系统性能有影响。当程序要读取的数据不在主存中时,会触发一个缺页异常,此时系统会向磁盘发出读盘信息,磁盘会找到数据的起始位置并向后连续读取一页或几页的数据载入内存中(系统从磁盘读取数据时是以磁盘块为基本单位的,位于同一磁盘块中的数据会被一次性读取出来,而不是按需读取),然后异常返回,程序继续运行。

    2.推理并拆解普通查询语句

    select * from talbe_name where id=1

    step1:找到数据文件

    step2:读取数据文件

    step3:读取id=1的数据

    理论上是这样的,索引是一种用来实现高效获取数据的数据结构,建索引的目的是为了查找的优化,特别是当数据很庞大的时候,非常重要。一般的查找算法有顺序查找、折半查找、快速查找等,但是每种查找算法只能应用于特定的数据结构,例如顺序查找依赖于顺序结构,折半查找通过二叉查找树或红黑树实现二分搜索。因此在数据之外,数据库系统还维护着满足特定查找算法的数据结构,它以某种方式引用数据。

    3.为什么要用B+Tree实现

    目前大多数数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。B+ 树中的 B (balance)代表平衡,而不是二叉。B+ 树是从最早的平衡二叉树演化而来的。B+ 树是由二叉查找树、平衡二叉树(AVLTree)和平衡多路查找树(B-Tree)逐步优化而来。

    • 二叉查找树:左子树的键值小于根的键值,右子树的键值大于根的键值。
    • AVL 树:平衡二叉树(AVL 树)在符合二叉查找树的条件下,还满足任何节点的两个子树的高度最大差为 1,但不是红黑树
    • 平衡多路查找树(B-Tree):为磁盘等外存储设备设计的一种平衡查找树。

    那么纠结该如何选型呢?

    索引的标准:IO渐进复杂度,说白了就是推演过程(每个节点都是1次IO),B+树是为磁盘及其他存储辅助设备而设计一种平衡查找树(不是二叉树),所有记录的节点按大小顺序存放在同一层的叶节点中,各叶节点用指针进行连接

    InnoDB 存储引擎使用页作为数据读取单位,页是其磁盘管理的最小单位,默认 page 大小是 16k。系统的一个磁盘块的存储空间往往没有这么大,因此 InnoDB 每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小 16KB。在查询数据时如果一个页中的每条数据都能助于定位数据记录的位置,这将会减少磁盘 I/O 的次数,提高查询效率。

    3.1 B-Tree

    B-树是一种多路自平衡的搜索树 它类似普通的平衡二叉树,不同的一点是B-树允许每个节点有更多的子节点。B-Tree 相对于 AVLTree 缩减了节点个数,使每次磁盘 I/O 取到内存的数据都发挥了作用,从而提高了查询效率。

    注:B-Tree就是我们常说的B树,一定不要读成B减树,否则就很丢人了

    那么m阶 B-Tree 是满足下列条件的数据结构:

    1. 所有键值分布在整颗树
    2. 搜索有可能在非叶子结点结束,在关键字全集内做一次查找,性能逼近二分查找
    3. 每个节点最多拥有m个子树
    4. 根节点至少有2个子树
    5. 分支节点至少拥有m/2颗子树(除根节点和叶子节点外都是分支节点)
    6. 所有叶子节点都在同一层、每个节点最多可以有m-1个key,并且以升序排列

    每个节点占用一个磁盘块,一个节点上有两个升序排序的关键字和三个指向子树根节点的指针,指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例,关键字为 17 和 35,P1 指针指向的子树的数据范围为小于 17,P2 指针指向的子树的数据范围为 17~35,P3 指针指向的子树的数据范围为大于 35。

    模拟查找关键字 29 的过程:

    1. 根据根节点找到磁盘块 1,读入内存。【磁盘 I/O 操作第 1 次】
    2. 比较关键字 29 在区间(17,35),找到磁盘块 1 的指针 P2。
    3. 根据 P2 指针找到磁盘块 3,读入内存。【磁盘 I/O 操作第 2 次】
    4. 比较关键字 29 在区间(26,30),找到磁盘块 3 的指针 P2。
    5. 根据 P2 指针找到磁盘块 8,读入内存。【磁盘 I/O 操作第 3 次】
    6. 在磁盘块 8 中的关键字列表中找到关键字 29。

    分析上面过程,发现需要 3 次磁盘 I/O 操作,和 3 次内存查找操作。由于内存中的关键字是一个有序表结构,可以利用二分法查找提高效率。而 3 次磁盘 I/O 操作是影响整个 B-Tree 查找效率的决定因素

    但同时B-Tree也存在问题:

    • 每个节点中有key,也有data,而每一个页的存储空间是有限的,如果data数据较大时将会导致每个节点(即一个页)能存储的 key 的数量很小。
    • 当存储的数据量很大时同样会导致 B-Tree 的深度较大,增大查询时的磁盘 I/O 次数,进而影响查询效率

    3.2 B+Tree

    B+Tree 是在 B-Tree 基础上的一种优化,InnoDB 存储引擎就是用 B+Tree 实现其索引结构。它带来的变化点:

    • B+树每个节点可以包含更多的节点,这样做有两个原因,一个是降低树的高度。另外一个是将数据范围变为多个区间,区间越多,数据检索越快
    • 非叶子节点存储key,叶子节点存储key和数据
    • 叶子节点两两指针相互链接(符合磁盘的预读特性),顺序查询性能更高

    注:MySQL 的 InnoDB 存储引擎在设计时是将根节点常驻内存的,因此力求达到树的深度不超过 3,也就是说 I/O 不需要超过 3 次。

    通常在B+Tree上有两个头指针,一个指向根节点,另一个指向关键字最小的叶子节点,而且所有叶子节点(即数据节点)之间是一种链式环结构。因此可以对 B+Tree 进行两种查找运算:一种是对于主键的范围查找和分页查找,另一种是从根节点开始,进行随机查找

    3.3 B-树和B+树的区别

    • B+树内节点不存储数据,所有数据存储在叶节点导致查询时间复杂度固定为 log n
    • B-树查询时间复杂度不固定,与 key 在树中的位置有关,最好为O(1)
    • B+树叶节点两两相连可大大增加区间访问性,可使用在范围查询等
    • B-树每个节点 key 和 data 在一起,则无法区间查找
    • B+树更适合外部存储(存储磁盘数据)。由于内节点无 data 域,每个节点能索引的范围更大更精确。

    3.4 MongoDB 为什么使用B-树

    B-树查询时间复杂度不固定,与 key 在树中的位置有关,最好为O(1)。尽可能少的磁盘 IO 是提高性能的有效手段。MongoDB 是聚合型数据库,而 B-树恰好 key 和 data 域聚合在一起

    至于MongoDB为什么使用B-树而不是B+树,可以从它的设计角度来考虑,它并不是传统的关系性数据库,而是以Json格式作为存储的nosql,目的就是高性能,高可用,易扩展。首先它摆脱了关系模型,上面所述的优点2需求就没那么强烈了,其次Mysql由于使用B+树,数据都在叶节点上,每次查询都需要访问到叶节点,而MongoDB使用B-树,所有节点都有Data域,只要找到指定索引就可以进行访问,无疑单次查询平均快于Mysql

    4.Mysql索引是如何实现的

    4.1 InnoDB 中的 B+Tree

    InnoDB 是通过 B+Tree 结构对 ID 建索引,然后在叶子节点中存储记录。采用 InnoDB 引擎的数据存储文件有两个,一个定义文件,一个是数据文件。

    若建索引的字段不是主键 ID,则对该字段建索引,然后在叶子节点中存储的是该记录的主键,然后通过主键索引找到对应的记录。

     

    4.2 Myisam 中的 B+Tree

    Myisam 引擎也是采用的 B+Tree 结构来作为索引结构。由于 Myisam 中的索引和数据分别存放在不同的文件,所以在索引树中的叶子节点中存的数据是该索引对应的数据记录的地址,由于数据与索引不在一起,所以 Myisam 是非聚簇索引。

    引用资料

    最后,哟没有感觉不是那么复杂了。

    展开全文
  • MySQL索引底层原理

    2019-05-21 23:26:56
    索引简介 索引是对数据库表中一个或多个列(例如,employee 表的姓名 (name) 列)的值进行排序的结构。 例如这样一个查询:select * from table1 where id=10000。如果没有索引,必须遍历整个表,直到ID等于10000...
  • MySQL索引底层实现原理

    千次阅读 多人点赞 2019-01-13 17:18:08
    MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。提取句子主干,就可以得到索引的本质:索引是数据结构。 我们知道,数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能...
  • 我们可以看到这条sql走的是主键的索引,而在mysql的InnoDB中,主键索引则是聚集索引,数据的物理顺序与键值的逻辑(索引)顺序相同,其实就是说主键索引跟其他列的数据是存在一起的。 并且我们可以看到key_len,当前...
  • 在介绍MYSQL索引底层原理之前,首先简单说说为什么MYSQL需要一个主键 主键:表中每一行都应该有可以唯一标识自己的一列(或一组列)。一个顾客可以使用顾客编号列,而订单可以使用订单ID,雇员可以使用雇员ID ...
  • MySQL底层索引原理

    2020-12-29 21:42:06
    MySQL索引分为很多种:主键索引、普通索引、联合索引等……这里主要讲主键、普通以及联合索引在两种存储引擎上的实现原理 例如: 1、 搭建 Java 开发环境 2、 掌握 Java 基本语法 3、 掌握条件语句 4、 掌握循环...
  • 索引(index)是帮助Mysql高效获取数据的数据结构。 所以,索引的本质的数据结构。 二、设计原理 为什么要使用索引,很容易想到的目前就是加快查询效率。因此数据库的设计者会从查询算法的角度上开始优化。最基本的...
  • 但是,网上的大多资料都没有提及,组合索引的具体实现。 我个人猜测组合索引也是使用一个 B-tree 来实现,其中关键字同时存储的是多个列的。 B-tree 根据多个列进行排序。这样正好可以很好地解释“最左前缀”...
  • mysql索引个人相关理解 每天多学一点点~ 话不多说,这就开始吧… 文章目录mysql索引个人相关理解1.索引到底是什么2.B-Tree3.B+Tree(B-Tree变种)4.MyISAM索引实现(非聚集)5.INNodb索引实现(聚集)6.联合索引7.结语 ...
  • MySql索引底层

    2019-08-16 16:03:56
    好久没有写博客了,前几天看了一个关于索引底层原理的学习视频,虽然是技术小白,但也是整理下自己学到或者理解的一些知识吧,不喜勿喷,欢迎交流! MySql索引的底层原理 1.索引的定义 MySQL官方对索引的定义为:...
  • MySQL索引笔记(索引底层原理索引是帮助MySQL高效获取数据的排好序的数据结构 索引数据结构 二叉树; 红黑树; Hash表; B-Tree; 二叉树 红黑树(二叉平衡树) 数据结构网站(https://www.cs.usfca.edu/~...
  • 假设一个组合索引的关键字为:age、name、height 这个组合索引在B+树结构下的数据结构如下: 联合索引也是一颗B+树,非叶子节点存储的是第一个关键字的索引,而叶子节点存储的事联合索引所有关键字的数据, 排列的...
  • mysql索引在使用不当情况下会失效. 比如:使用最佳左前缀法则,大于号右边的索引会失效,使用like索引会失效,当准备面试的时候我们为了应付面试的的时候往往会去找到这些面试题目的答案,但是往往不会去思考,...
  • 索引(Index)是帮助MySQL高效获取数据的数据结构,为什么需要需要特定的数据结构呢?首先,顺序查找这种复杂度为O(n)的算法在数据量很大时显然是糟糕的,更优秀的查找算法,比如二分查找(binary search)、二叉树...
  • B+TREE b+tree 是innodb存储引擎的底层结构, 如果想知道innodb如何存储数据, 首先需要掌握b+t're
  • 深入解析了Mysql的B+Tree索引底层数据结构,以及MyISAM和InnoDB 存储引擎的索引底层原理
  • mysql组合索引中最左前缀匹配原理

    千次阅读 2017-10-15 22:49:08
    在上文中,我们都是假设索引只引用了单个的列,实际上,MySQL中的索引可以以一定顺序引用多个列,这种索引叫做联合索引,一般的,一个联合索引是一个有序元组,其中各个元素均为数据表的一列。另外,单列索引可以...
  • 全文检索 一.概述 1.1 全文检索的概念 全文检索就是将存储于数据库中的整本书或整篇文章中的...MySql中的InnoDB存储引擎中对于表索引的管理是采用B+树结构的,所以我们可以通过索引字段的前缀进行查找。例如: select
  • MySql索引底层数据结构和算法 MySql explan执行计划详解 优化原则实例sql准备 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_name` varchar(24) NOT NULL DEFAULT '' COMMENT '用户姓名', ...
  • 博文目录 文章目录索引的数据结构为什么不用二叉树做索引为什么不用红黑树做索引B树B+树B树和B+树的区别B...组合索引(联合索引)组合索引的最左前缀原则为什么组合索引有最左前缀原则 MySQL索引原理及慢查询优化 硬盘
  • MySql索引实现原理

    千次阅读 2015-01-18 17:26:55
    MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。提取句子主干,就可以得到索引的本质:索引是数据结构。 我们知道,数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能...
  • 1、索引数据结构2、InnoDB索引的设计(1)计算机原理(2)查找过程(3)聚族索引与二级索引(4)创建索引索引的类型(5)索引的缺点(6)外键及作用 1、索引数据结构 哈希索引(Hash indexes)采用哈希表来对键值...
  • mysql数据库底层原理

    千次阅读 2020-05-18 21:47:19
    一、MySQL 的基本定义: A.术语介绍 1. 数据库(Database) 是按照数据结构来组织、存储和管理数据的仓库。 每个数据库都有一个或多个不同的API用于创建、访问、管理、搜索和复制所保存的数据。 2. RDBMS...
  • 1 什么是索引索引是帮助数据库高效获取数据的拍好序的 数据结构 。 为什么使用索引? 先来看一个小例子:假设一个数据表 table1 中有两列数据,分别是col1和col2 ,现在要执行语句 select * from table1 where ...
  • 想进大厂,这些MySQL索引底层知识你必须掌握

    千次阅读 多人点赞 2021-09-03 14:45:12
    想进大厂,这些MySQL索引底层知识你必须掌握
  • MySQL索引类型 一、简介 ...4.组合索引 5.全文索引 二、语句 CREATE TABLE table_name[col_name data type] [unique|fulltext][index|key][index_name](col_name[length])[asc|desc] 1.u...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,072
精华内容 5,628
热门标签
关键字:

mysql组合索引底层原理

mysql 订阅