MySQL存储引擎以及索引原理

一、MySQL存储引擎:MySQL将数据用各种不同的技术存储在文件中,这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。这些不同的技术以及配套的相关功能在 mysql中被称作存储引擎(也称作表类型)。建表时,选择合适的存储引擎很重要,如果到后期再更换将会很麻烦。存储引擎是基于表的,而非数据库。

个人理解:存储引擎是某张表存储数据、如何为存储的数据建立索引和更新、查询数据库等技术的实现方法集合及约束。常见的存储引擎如下图:

这里,先总结常用的三种存储引擎:

1. MyISAM引擎:MyISAM引擎是MySQL默认的存储引擎,MyISAM不支持事务和行级锁,所以MyISAM引擎速度很快,性能优秀。MyISAM可以对整张表加锁,支持并发插入,支持全文索引。

缺点:不支持事务和行级锁,也不支持外键

优点:访问速度快,对事务的完整性没有要求或者以select、insert为主的应用基本上都可以使用这个引擎来创建

    MyISAM再磁盘上存储成三个文件,其文件名都和表名相同,但扩展名分别是:.frm(存储表定义),.MYD(存储数据),.MYI(存储索引)这种引擎又可以分为静态MyISAM、动态MyISAM 和压缩MyISAM三种:

静态MyISAM:如果数据表中的各数据列的长度都是预先固定好的,服务器将自动选择这种表类型。因为数据表中每一条记录所占用的空间都是一样的,所以这种表存取和更新的效率非常高。当数据受损时,恢复工作也比较容易做。

动态MyISAM:如果数据表中出现varchar、xxxtext或xxxBLOB字段时,服务器将自动选择这种表类型。相对于静态MyISAM,这种表存储空间比较小,但由于每条记录的长度不一,所以多次修改数据后,数据表中的数据就可能离散的存储在内存中,进而导致执行效率下降。同时,内存中也可能会出现很多碎片。因此,这种类型的表要经常用optimize table 命令或优化工具来进行碎片整理。

压缩MyISAM:以上说到的两种类型的表都可以用myisamchk工具压缩。这种类型的表进一步减小了占用的存储,但是这种表压缩之后不能再被修改。另外,因为是压缩数据,所以这种表在读取的时候要先时行解压缩。

但是,不管是何种MyISAM表,目前它都不支持事务,行级锁和外键约束的功能。

(补充:锁

页级:引擎 BDB。

表级:引擎 MyISAM , 理解为锁住整个表,可以同时读,写不行

行级:引擎 INNODB , 单独的一行记录加锁

上述三种锁的特性可大致归纳如下:

1) 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。

2) 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。

3) 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

三种锁各有各的特点,若仅从锁的角度来说,表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如WEB应用;行级锁更适合于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理(OLTP)系统。

-->MySQL表级锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。就是说对MyISAM表进行读操作时,它不会阻塞其他用户对同一表的读请求,但会阻塞 对同一表的写操作;而对MyISAM表的写操作,则会阻塞其他用户对同一表的读和写操作。当一个进程请求某个MyISAM表的读锁,同时另一个进程也请求同一表的写锁时,通常写进程优先获得锁。

-->InnoDB有两种模式的行锁:

1)共享锁:允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁。

( Select * from table_name where ......lock in share mode)

2)排他锁:允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和  排他写锁。(select * from table_name where.....for update)

★ InnoDB行锁是通过给索引项加锁来实现的,由于InnoDB预设是Row-Level Lock,所以只有「明确」的指定主键,MySQL才会执行Row lock (只锁住被选取的资料例) ,否则MySQL将会执行Table Lock (将整个资料表单给锁住)。

SELECT * FROM products WHERE id=‘3‘ FOR UPDATE; --row-level lock

SELECT * FROM products WHERE name=‘Mouse‘ FOR UPDATE; --table-level lock

★ 死锁产生的根本原因是两个以上的进程都要求对方释放资源,以至于进程都一直等待。在代码上是因为两个或者以上的事务都要求另一个释放资源。死锁产生的四个必要条件:互斥条件、环路条件、请求保持、不可剥夺,缺一不可,相对应的只要破坏其中一种条件死锁就不会产生。

2. InnoDB引擎:InnoDB是专为事务设计的存储引擎,支持事务,支持外键,拥有高并发处理能力。但是,InnoDB在创建索引和加载数据时,比MyISAM慢。

1.自动增长列:通过“alter table *** auto_increment = n”语句强制设置自动增长列的初始值,如果在使用之前重新启动数据库,则需要重新设置,不设置默认初始值为1.对于InnoDB表来说自动增长列必须是索引。如果是组合索引,也必须是组合索引的第一列,但是对于MyISAM表,自动增长列可以是组合索引的其他列,这样插入记录后,自动增长列按照组合索引前面几列进行排序后递增的。

2.外键约束:MySQL支持外键的存储引擎只有InnoDB,在创建外键的时候,要求父表必须有对应的索引,子表在创建外键的时候也会自动创建对应的索引。当某个表被其他表创建的外键参照,那么该表的对应索引或者主键禁止被删除。在导入多个表的数据时,如果需要忽略表之前的导入顺序,可以暂时关闭外键的检查,在处理LOAD DATA 和 ALTER TABLE操作的时候,可以关闭外键约束来加快处理速度,“set foreign_key_checks = 0(1开)”。对于InnoDB类型的表,外键信息通过使用show
table status命令显示。

3.存储方式:InnoDB存储表和索引有以下两种方式。①.使用共享表空间存储,这种方式创建的表的表结构保存在.frm文件中,数据和索引保存在innodb_data_home_dir和innodb_data_file_path定义的表空间中,可以是多个文件。②.使用多表空间存储,这种方式创建的表的表结构仍然保存在.frm文件中,但是每个表的数据和索引单独保存在.ibd中。如果是分区表,则每个分区对应单独的.ibd文件,文件名是“表名+分区名”,可以在创建分区的时候指定每个分区的数据文件的位置,一次来将表的IO均匀的分布在多个磁盘上。要使用多表空间的存储方式,需要设置参数innodb_file_per_table,并且重启服务才能生效,对于新建的表按照多表空间的方式创建,已经有的仍然使用共享表空间存储。多表空间的数据文件没有大小限制,不需要设置初始化大小,也不需要设置文件的最大限制、扩展大小等参数。对于使用多表空间特性的表,可以比较方便地进行单表备份和恢复操作。

3. Memory引擎(采用哈希索引):内存表,Memory引擎将数据存储在内存中,表结构不是存储在内存中的,查询时不需要执行磁盘I/O操作,所以要比MyISAM和InnoDB快很多倍,但是数据库断电或是重启后,表中的数据将会丢失,表结构不会丢失.

★ 如何选择存储引擎:

  在选择存储引擎时,应根据应用特点选择合适的存储引擎。对于复杂的应用系统,还可以根据实际情况选择多种存储引擎进行组合。

MyISAM:默认的Mysql插件式存储引擎(5.5之前)。如果应用是以读操作和插入操作为主,只有少量的更新和删除操作,并且对事务的完整性、并发性要求不是很高,那么选择这个存储引擎非常合适。例如:Web、数据仓库和其他应用环境下最常用的存储引擎之一。

  InnoDB:用于处理事务应用程序,支持外键。如果应用对事务的完整性有较高的要求,在并发条件下要求数据的一致性,数据除了插入查询之外,还包括很多的更新、删除操作,那么InnoDB存储引擎应该是比较合适的。InnoDB存储引擎除了有效的降低由于删除和更新导致的锁定,还可以确保事务的完整的提交和回滚,对于类似计费系统或者财务系统等对数据准确性要求比较高的系统,InnoDB都是合适的选择。

  MEMORY:将所有的数据保存在RAM中,在需要快速定位记录和其他类似数据的环境下,可提供几块的访问,MEMORY的缺陷是对表的大小有限制,太大的表无法缓存在内存中,其次是要确保表的数据可以恢复,数据库异常终止后表中的数据数据是可以恢复的。MEMORY表通常更新不太频繁的小表,用以快速得到访问结果。

 MERGE:用于将一系列的MyISAM表以逻辑方式组合在一起,并作为一个对象引用它们。有点突破了单个MyISAM表大小的限制,并且通过将不同的表分布在多个磁盘上,可以有效地改善MERGE表的访问效率。这对于数据仓库等VLDB(超大型数据库)环境十分合适。

★ MySql中关于存储引擎的操作:

1.  用show engines; 命令可以显示当前数据库支持的存储引擎情况;

2. Show create table tablename; //显示表的创建语句;

3. show table status like ‘tablename’; //显示表的当前状态值;

4. 创建数据库表时设置存储存储引擎的基本语法是:

Create table tableName(

columnName(列名1)  type(数据类型)  attri(属性设置),

columnName(列名2)  type(数据类型)  attri(属性设置),

……..) engine = engineName

5. 修改存储引擎,可以用命令Alter table tableName engine =engineName

二、索引原理

1. 索引(在MySQL中也叫做键<key>),是存储引擎用于快速找到记录的一种数据结构。索引本身很大,不可能全部存储在内存中,因此索引以索引表的形式存储在磁盘中。

2. 理解索引也是进行数据库性能调优的起点。很多时候,当应用程序进行SQL查询速度很慢时,应该想想是否可以建索引。索引优化应该是对查询性能优化最有效的手段,索引能够轻易将查询性能提高几个数量级,”最优“的索引有时比一个”好的“索引性能要好两个数量级。创建一个真正”最优“的索引经常要重写查询。

3. 在mysql中,存储引擎用一本书的“索引”找到对应页码类似的方法使用索引,其先在索引中找到对应值,然后根据匹配的索引记录找到对应的数据行。索引可以包含一个或多个列的值。如果索引包含多个列,那么列的顺序也十分重要,因为MySQL只能高效地使用索引的最左前缀列,假设存在组合索引 idx_t1_c1_c2(c1,c2),查询语句select * from t1 where c1=1 and c2=2能够使用该索引。查询语句select *
from t1 where c1=1也能够使用该索引。但是,查询语句select * from t1 where c2=2不能够使用该索引,因为没有组合索引的引导列,即,要想使用c2列进行查找,必需出现c1等于某值。

4. 选择索引的数据类型:MySQL支持很多数据类型,选择合适的数据类型存储数据对性能有很大的影响。通常来说,可以遵循以下一些指导原则:

(1) 越小的数据类型通常更好:越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间,处理起来更快。

(2) 简单的数据类型更好:整型数据比起字符,处理开销更小,因为字符串的比较更复杂。在MySQL中,应该用内置的日期和时间数据类型,而不是用字符串来存储时间;以及用整型数据类型存储IP地址。

(3) 尽量避免NULL:应该指定列为NOT NULL,除非你想存储NULL。在MySQL中,含有空值的列很难进行查询优化,因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。

5. 索引的类型:索引是在存储引擎中实现的,而不是在服务器层中实现的。所以,每种存储引擎的索引都不一定完全相同,并不是所有的存储引擎都支持所有的索引类型。

★ B-Tree索引:每一个叶子节点都包含指向下一个叶子节点的指针,从而方便叶子节点的范围遍历。B-Tree通常意味着所有的值都是按顺序存储的,并且每一个叶子页到根的距离相同,很适合查找范围数据。

★ B+树索引:并不能找到一个给定健值的具体行,B+树索引只能找到被查找数据行所在的页,然后从数据库将页读入内存,在内存中查找。B+树索引可以分为聚集索引和辅助索引。聚簇索引是按照数据存放的逻辑地址为顺序的,而非聚簇索引就不一样了;聚簇索引能提高多行检索的速度,而非聚簇索引对于单行的检索很快。

○ 聚集索引 :聚集索引是一种索引组织形式,索引的键值逻辑顺序决定了表数据行的物理存储顺序。 聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后,便可以确保包含后续索引值的行在物理相邻。

InnoDB的数据文件本身要按主键聚集,所以InnoDB要求表必须有主键(MyISAM可以没有),如果没有显式指定,则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL自动为InnoDB表生成一个隐含字段作为主键,这个字段长度为6个字节,类型为长整形。

○ 辅助索引:叶结点的data域存放的是对应记录的主键的key。 对于建立辅助索引的表需要先根据辅助索引找到相应的主键,再根据主键在聚集索引中找到相应的记录集。

○ 非聚集索引

非聚集索引则就是普通索引了,仅仅只是对数据列创建相应的索引,不影响整个表的物理存储顺序。主键索引中,叶节点的data域存放的是数据记录的地址,如果指定的Key存在,则取出其data域的值,然后以data域的值为地址,读取相应数据记录。(MYISAM采用此种索引方式)。

区别

聚集索引表里数据物理存储顺序和主键索引的顺序一致,所以如果新增数据是离散的,会导致数据块趋于离散,而不是趋于顺序。而非聚集索引表数据写入的顺序是按写入时间顺序存储的。聚簇索引索引的叶节点就是数据节点;而非聚簇索引的叶节点仍然是索引节点,只不过有一个指针指向对应的数据块。

适用情景

★ Hash索引:哈希索引基于哈希表实现,只有精确索引所有列的查询才有效。对于每一行数据,存储引擎都会对所有的索引列计算一个哈希码,哈希码是一个较小的值,并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希存储在索引中,同时在哈希表中保存指向每个数据的指针。

哈希索引中存储的是:哈希值+数据行指针

MySQL中,只有Memory存储引擎显示支持hash索引,是Memory表的默认索引类型,尽管Memory表也可以使用B-Tree索引。Memory存储引擎支持非唯一hash索引,这在数据库领域是罕见的,如果多个值有相同的hash code,索引把它们的行指针用链表保存到同一个hash表项中。

索引有如下优点与缺点:

★ 优点

1.可以通过建立唯一索引或者主键索引,保证数据库表中每一行数据的唯一性

2.建立索引可以大大提高检索的数据,以及减少表的检索行数

3.在表连接的连接条件,可以加速表与表直接的相连

4.在分组和排序字句进行数据检索,可以减少查询时间中分组和 排序时所消耗的时间(数据库的记录会重新排序)

5.建立索引,在查询中使用索引,可以提高性能

--索引大大减小了服务器需要扫描的数据量

--索引可以帮助服务器避免排序和临时表

--索引可以将随机IO变成顺序IO

△ 缺点

1.创建索引和维护索引会耗费时间,随着数据量的增加而增加

2.索引文件会占用物理空间,除了数据表需要占用物理空间之外,每一个索引还会占用一定的物理空间

3.当对表的数据进行 INSERT,UPDATE,DELETE 的时候,索引也要动态的维护,这样就会降低数据的维护速度,(建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重,但如果你在一个大表上创建了多种组合索引,索引文件的会膨胀很快)。

索引的使用:最好的做法是创建表的时候创建索引,如果创建表之后再修改新建索引的话,对于聚集索引,会根据原来的表,创建一个新的表带有索引数据结构,再把原来的表删去,新创建的表改成原来的表的名字。而非聚集索引则是通过修改索引文件来完成。所以都是需要占用额外的资源来修改或新建索引的。

①. 普通索引:

# 创建表的同时创建索引

CREATE TABLE `artical` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`subject` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL,

`time` Date NULL DEFAULT NULL,

PRIMARY KEY(`id`),

INDEX index_subject (subject)

);

# 直接创建索引

CREATE INDEX <index_name> ON <table_name>(<column_name>);

# 修改表结构的方式添加索引

ALTER TABLE <table_name> ADD INDEX index_name (<column_name>);

②. 唯一索引

与普通索引的不同的是,索引列的值必须唯一,但允许有空值。如果是组合索引,则列值的组合必须唯一。

# 创建表的时候直接指定

CREATE TABLE `user` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` char(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

`tel` char(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

PRIMARY KEY(`id`),

UNIQUE index_subject (name)

);

# 直接创建索引

CREATE UNIQUE INDEX <index_name> ON <table_name>(<column_name>);

# 修改表结构的方式添加索引

ALTER TABLE <table_name> ADD UNIQUE index_name (<column_name>);

③. 主键索引

索引值必须唯一,不能为NULL,在B+TREE中的InnoDB引擎中,主键索引起到了至关重要的地位。

④. 全文索引

MySQL从3.23.23版开始支持全文索引和全文检索,FULLTEXT索引仅可用于 MyISAM 表;他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建,或是随后使用ALTER TABLE 或CREATE INDEX被添加。

# 创建表的时候添加全文索引

CREATE TABLE `artical` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`subject` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,

`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL,

`time` Date NULL DEFAULT NULL,

PRIMARY KEY(`id`),

FULLTEXT (content)

)engine=MyISAM;

# 修改表结构添加全文索引

ALTER TABLE artical ADD FULLTEXT INDEX index_content(content);

# 直接创建索引

CREATE FULLTEXT INDEX index_content ON artical(content);

⑤. 单列索引,多列索引

多个单列索引与单个多列索引的查询效果不同,因为执行查询时,MySQL只能使用一个索引,会从多个索引中选择一个限制最为严格的索引。

⑥. 组合索引

平时用的SQL查询语句一般都有比较多的限制条件,所以为了进一步榨取MySQL的效率,就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引:ALTER TABLE article ADD INDEX index_titme_time (subject,title(50),time(10)),实际上包含三个索引(subject),(subject, title), (subject, title, time)。

在使用查询的时候遵循“最左前缀”:不按索引最左列开始查询不适用索引。例如对idnex(c1,c2,c3),使用where c2 = “aaa” and c3 = “bbb”不能使用索引

查询中某个列有范围查询,则其右边的所有列都无法使用查询。例如对idnex(c1,c2,c3),where c1 = “xxx” and c2 like = “aa%” and c3 = “sss”查询只会使用索引的前两列,因为like是范围查询不能跳过某个字段进行查询。

参考文章:

https://blog.csdn.net/Juwenzhe_HEBUT/article/details/77711832

原文地址:https://www.cnblogs.com/twoheads/p/9706543.html

时间: 2024-10-12 19:24:29

MySQL存储引擎以及索引原理的相关文章

MySQL存储引擎,索引及基本优化策略

存储引擎 与Oracle, SQL Server这些数据库不同,MySQL提供了多种存储引擎.什么是存储引擎?存储引擎其实就是一套对于数据如何存储,查询,更新,建立索引等接口的实现.不同存储引擎特性有所不同,我们根据需要进行选择,比如包含ETL操作的OLTP(联机交易处理)项目中我们通常选择InnoDB,而对于读操作较多几乎没有写操作的OLAP(联机分析处理)则选MyISAM的更多.因此并不是大家都用环境相似,同一版本的MySQL,能够使用的特性就是一致的.在MySQL终端中查看支持的存储引擎,

MySql 存储引擎和索引

存储引擎 什么是数据库存储引擎? 数据库引擎是数据库底层软件组件,不同的存储引擎提供不同的存储机制,索引技巧,锁定水平等功能,使用不同的数据库引擎,可以获得特定的功能 如何查看引擎? --如何查看数据库支持的引擎 show engines; ? --查看当前数据的引擎: show create table 表名\G ? --查看当前库所有表的引擎: show table status\G 建表时指定引擎 create table yingqin (id int,name varchar(20))

MySql存储引擎+表解压缩机制+索引+查询缓存机制+慢查询日志

一.大型网站优化之MySql优化 1.优化和不优化的对比的 在业界当中我们有一个叫大数据(big data)的概念,所谓的大数据指代千万级别以上的数据作为起步的数据.所以我们现在需要对两张都具有50331650条记录的表进行查询对比,其中表名为tbl_no的表是没有做过任何优化手段的表,表名为tbl_yes的表是做过优化手段的表.这个实验的目的是观察具有优化手段和不具有优化手段的查询中速度的差别. 实验条件: 1)两张表的数据记录总数是相同的 2)两张表的数据字段结构也是一样的 3)查询的记录的

mysql 存储引擎,字段类型,索引介绍

一:常用的存储引擎:1,myisam:    我建立了一个MyISAM引擎的tb_Demo表,那么就会生成以下三个文件:     1>tb_demo.frm,存储表定义:     2>tb_demo.MYD,存储数据:     3>tb_demo.MYI, 存储索引.   特点: 查询快,写入慢,支持表锁,支持符合全文索引    适合管理邮件,web服务器的日志数据,选择密集结构表的时候用,插入密集结构   表的时候用2,innodb     1>更新密集的表.InnoDB存储引擎

重新学习MySQL数据库3:Mysql存储引擎与数据存储原理

重新学习Mysql数据库3:Mysql存储引擎与数据存储原理 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识,觉得数据库就是一堆数据的集合,但是实际却比这复杂的多,数据库领域中有两个词非常容易混淆,也就是数据库和实例: 数据库:物理操作文件系统或其他形式文件类型的集合: 实例:MySQL 数据库由后台线程以及一个共享内存区组成: 对于数据库和实例的定义都来自于 MySQL 技术内幕:InnoDB 存储引擎 一书,想要了解 InnoDB 存储引擎的读者可以阅读这本书籍. 数据

Mysql的存储引擎和索引

2 Mysql的存储引擎和索引 可以说数据库必须有索引,没有索引则检索过程变成了顺序查找,O(n)的时间复杂度几乎是不能忍受的.我们非常容易想象出一个只有单关键字组成的表如何使用B+树进行索引,只要将关键字存储到树的节点即可.当数据库一条记录里包含多个字段时,一棵B+树就只能存储主键,如果检索的是非主键字段,则主键索引失去作用,又变成顺序查找了.这时应该在第二个要检索的列上建立第二套索引.  这个索引由独立的B+树来组织.有两种常见的方法可以解决多个B+树访问同一套表数据的问题,一种叫做聚簇索引

MySQL索引创建与删除,MySQL存储引擎的配置

MySQL索引创建与删除 1.1 问题 本案例要求熟悉MySQL索引的类型及操作方法,主要练习以下任务: 普通索引.唯一索引.主键索引的创建/删除 自增主键索引的创建/删除 建立员工表yg.工资表gz,数据内容如表-1.表-2所示,设置外键实现同步更新与同步删除 表-1 员工表yg的数据 表-2 工资表gz的数据 1.2 步骤 实现此案例需要按照如下步骤进行. 步骤一:索引的创建与删除 创建表的时候指定INDEX索引字段 创建库home: mysql> create database home;

02: MySQL 索引类型 、 MySQL 存储引擎

day02一.mysql索引二.MySQL存储引擎+++++++++++++++++++++++++++++++++++一.mysql索引1.1 索引介绍 : 相当于 "书的目录" 5000页1~200 目录信息拼音排序部首排序笔画排序 201~5000 正文 1.2 索引的优点与缺点?优点 加快查询的速度缺点 占用物理存储空间,减慢写的速度. 姓名 性别 班级 年龄jimjimNULL 1.3 使用普通索引index:(在表中的字段上创建索引)使用规则?查看 desc 表名: key

为什么用B+树做索引&amp;MySQL存储引擎简介

索引的数据结构 为什么不是二叉树,红黑树什么的呢? 首先,一般来说,索引本身也很大,不可能全部存在内存中,因此索引往往以索引文件的方式存在磁盘上.然后一般一个结点一个磁盘块,也就是读一个结点要进行一次IO操作. 而二叉树啊这些树类的数据结构,查找时间主要和树的高度有关,所以虽然一颗AVL树或者是红黑树在查找上比起顺序遍历的O(N)有了比较大的改善,但B树和B+树因为每个结点存的元素更多,所以查询更快,对磁盘的IO操作也更少. 为什么是B+树而不是B树呢? 1. 单一节点存储更多的元素(这样该节点