mysql默认存储引擎的命令？

一、mysql默认存储引擎的命令？

MySQL默认存储引擎为InnoDB，可以通过使用命令SHOW VARIABLES LIKE 'storage_engine';

一、InnoDB存储引擎

1.InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID）

　（MyISAM：不支持事务；只支持表级锁)

事务的ACID属性：即原子性、一致性、隔离性、持久性

a.原子性：原子性也就是说这组语句要么全部执行，要么全部不执行，如果事务执行到一半出现错误，数据库就要回滚到事务开始执行的地方。

实现：主要是基于MySQ日志系统的redo和undo机制。事务是一组SQL语句，里面有选择，查询、删除等功能。每条语句执行会有一个节点。例如，删除语句执行后，在事务中有个记录保存下来，这个记录中储存了我们什么时候做了什么事。如果出错了，就会回滚到原来的位置，redo里面已经存储了我做过什么事了，然后逆向执行一遍就可以了。

b.一致性：事务开始前和结束后，数据库的完整性约束没有被破坏。（eg:比如A向B转账，不可能A扣了钱，B却没有收到）

c.隔离性：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰；

如果不考虑隔离性则会出现几个问题。

i、脏读：是指在一个事务处理过程里读取了另一个未提交的事务中的数据（当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致）；（读取了另一个事务未提交的脏数据）

ii、不可重复读：在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了；（读取了前一个事务提交的数据，查询的都是同一个数据项。

iii、幻读：是事务非独立执行时发生的一种现象（eg:事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样）；（读取了前一个事务提交的数据，针对一批数据整体）

d.持久性：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚

2.InnoDB是mySQL默认的存储引擎，默认的隔离级别是RR，并且在RR的隔离级别下更近一步，通过多版本并发控制（MVCC）解决不可重复读问题，加上间隙锁（也就是并发控制）解决幻读问题。因此InnoDB的RR隔离级别其实实现了串行化级别的效果，而保留了比较好的并发性能。

二、mysql默认的存储引擎是？

mysql默认引擎：mysql-5.1版本之前默认引擎是MyISAM，之后是innoDB

MyISAM是非集聚引擎，支持全文索引;不支持事务;它是表级锁;会保存表的具体行数.

　　innoDB是集聚引擎，5.6以后才有全文索引;支持事务；它是行级锁;不会保存表的具体行数.

一般：不用事务的时候,count计算多的时候适合myisam引擎。对可靠性要求高就是用innodby引擎。

三、mysql数据库引擎myisam和innerdb的区别？

InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。

以下是一些细节和具体实现的差别：

◆1.InnoDB不支持FULLTEXT类型的索引。

◆2.InnoDB中不保存表的具体行数，也就是说，执行selectcount(*)fromtable时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含where条件时，两种表的操作是一样的。

◆3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

◆4.DELETEFROMtable时，InnoDB不会重新建立表，而是一行一行的删除。

◆5.LOADTABLEFROMMASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。

另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如updatetablesetnum=1wherenamelike“%aaa%”

两种类型最主要的差别就是Innodb支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，selectcount(*)和orderby是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些selectcount(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

四、mysql 引擎

在网站或应用程序开发中，一个稳定的数据库是至关重要的，而MySQL是开发者们经常选择的关系型数据库系统之一。MySQL提供了多种引擎来处理数据的存储和检索，不同的引擎有不同的特性和适用场景。

MySQL引擎的选择

选择正确的MySQL引擎对于应用程序的性能和可靠性至关重要。以下是一些常见的MySQL引擎：

InnoDB： 这是MySQL的默认引擎。它支持事务处理和行级锁定，适合频繁更新的应用程序。
MyISAM： 它是MySQL 5.5之前的默认引擎，不支持事务处理，但是在读操作较多的情况下具有较快的速度。
Memory： 这个引擎将数据存储在内存中，因此具有非常快的读写速度，但是数据会在服务器重启时丢失。
Archive： 这个引擎专门用于存档数据，对于需要长期保存数据但很少查询的场景非常适用。

InnoDB引擎的特点

在众多MySQL引擎中，InnoDB是最常用的引擎之一。下面是一些InnoDB引擎的特点：

支持事务：InnoDB引擎提供了事务处理的能力，保证了数据的一致性和可靠性。
行级锁定：InnoDB通过行级锁定来控制对数据的并发访问，降低了锁冲突的可能性。
外键约束：InnoDB允许定义和管理外键，保证了数据的完整性。
崩溃恢复：InnoDB具有强大的崩溃恢复能力，可以在服务器重启后恢复数据。

MyISAM引擎的特点

MyISAM引擎在某些特定场景下也是一个不错的选择。它具有以下特点：

速度快：MyISAM引擎在读操作方面性能较好，适合于大量的只读查询。
全文搜索：MyISAM引擎支持全文搜索索引，在需要进行全文搜索的应用中具有优势。
低存储空间：相比InnoDB引擎，MyISAM引擎在存储空间方面更加紧凑。

选择恰当的MySQL引擎

选择适合的MySQL引擎需要根据应用程序的具体需求和特点来决定。以下是一些建议：

对于需要支持事务处理和并发操作的应用，InnoDB是一个较好的选择。
对于主要进行读操作的应用，可以考虑使用MyISAM引擎以提高查询性能。
如果应用需要频繁更新数据并支持外键约束，那么选用InnoDB引擎是明智的选择。
如果数据是临时性的，可以选择Memory引擎以获得更快的读写速度。
对于需要长期保存但很少查询的存档数据，可以选择Archive引擎以减少存储空间。

总结

选择适合的MySQL引擎是保证应用程序性能和可靠性的重要一步。不同的引擎具有不同的特点和适用场景，开发者应该根据自己的需求来进行选择。InnoDB引擎适合需要支持事务处理和外键约束的应用，而MyISAM引擎适合主要进行读操作的应用。其他引擎如Memory引擎和Archive引擎也有着各自的特点和优势。

了解MySQL引擎的特点和适用场景将有助于开发者更好地选择合适的引擎，从而提高应用程序的性能和可靠性。

五、mysql引擎

MySQL引擎：数据库是现代应用程序的关键部分，在数据存储和检索方面扮演着重要角色。其中，MySQL是最受欢迎的关系型数据库管理系统之一。MySQL引擎是决定MySQL数据库底层工作原理的核心组件之一。MySQL支持多种引擎，每个引擎都有不同的特点和适用场景。本文将深入探讨几个常见的MySQL引擎，帮助读者更好地选择合适的引擎来满足他们的需求。

1. InnoDB 引擎

InnoDB是MySQL的默认存储引擎，它提供了强大的事务支持和高级的并发控制。InnoDB引擎使用行级锁定，能够处理高并发的读写操作，保证数据的完整性和一致性。它使用“提交，回滚和崩溃恢复”机制来保证数据的可靠性。InnoDB引擎还支持外键约束和自动增量列等高级功能。

InnoDB引擎适用于需要频繁更新和查询数据的应用，例如电子商务网站、博客平台、会员系统等。它在处理大量并发事务时表现出色，并且能够有效利用多核处理器的优势。然而，InnoDB的存储空间占用较大，对于大型数据库来说，需要更多的磁盘空间来存储数据。

2. MyISAM 引擎

MyISAM是在InnoDB引擎之前最常用的MySQL引擎。它使用表级锁定来处理并发请求。这意味着在更新数据时，整个表将被锁定，其他查询必须等待。MyISAM引擎不支持事务，也不支持外键约束等高级功能。然而，它的存储效率高，不需要额外的存储空间。

MyISAM引擎适用于读密集型应用，例如新闻网站、博客平台等。它在处理大量的并发读取请求时表现出色。由于没有事务的支持，MyISAM引擎在数据库崩溃后的恢复过程较为简单和快速。

3. Memory 引擎

Memory引擎也被称为Heap引擎，它将数据存储在内存中，而不是磁盘上。这使得Memory引擎具有极快的访问速度。然而，由于数据存储在内存中，一旦服务器重启或崩溃，所有数据将会丢失。因此，Memory引擎适用于临时表、缓存数据等不需要长时间存储的情况。

Memory引擎不支持事务和外键约束，并且只支持基本的索引类型。它对数据的操作速度非常快，适用于高性能的数据计算和临时数据存储。如果应用需要持久的数据存储和复杂的数据操作，建议使用其他支持事务的引擎。

4. Archive 引擎

Archive引擎专门用于存储归档数据。它通过压缩和存档技术，将数据存储在磁盘上，以节约存储空间。Archive引擎的读取速度较慢，不支持索引和并发操作，但在存储大量历史数据和备份数据时非常有用。

Archive引擎适用于需要长期存储大量数据的应用，例如日志系统、数据仓库等。由于数据被压缩存储，Archive引擎占用的磁盘空间非常小。然而，如果应用需要频繁访问和修改数据，建议选择其他更适合的引擎。

结论

MySQL引擎的选择是根据具体应用需求来决定的。根据应用的读写比例、事务需求和存储空间等方面的考虑，选择合适的引擎能够提升数据库性能和使用效率。InnoDB引擎适用于高并发的读写操作，提供了强大的事务支持；MyISAM引擎适用于读密集型应用，具有高存储效率；Memory引擎适用于临时表和缓存数据等场景，提供了快速的数据访问；Archive引擎适用于存储归档数据，节约存储空间。

在选择MySQL引擎时，需要综合考虑应用的需求和数据库的特点，选择最合适的引擎来优化数据库性能和数据存储效率。

六、mysql数据库默认的引擎和表指定的引擎有什么区别？

如果你的数据库表有指定存储引擎,那么数据库的默认引擎配置是不生效的,当且仅当你在建表语句中没有指定所使用的引擎,此时这个表的存储引擎就会是数据库中配置的默认引擎

七、mysql存储引擎

MySQL存储引擎是MySQL数据库的核心组成部分之一，在数据库管理系统中具有至关重要的作用。MySQL存储引擎负责处理数据的存储、检索和操作，它决定了数据库在物理存储层面上的结构和管理方式。

什么是MySQL存储引擎？

MySQL存储引擎是一种用于处理和组织数据存储的软件模块。每个存储引擎都有其独特的特性和适用场景，可以根据具体需求选择合适的存储引擎。MySQL支持多种存储引擎，包括最常见的InnoDB、MyISAM、MEMORY等。

InnoDB：强大的事务支持

InnoDB是MySQL最受欢迎和广泛使用的存储引擎之一。它提供了完整的事务支持和行级锁定，适用于需要高并发读写的应用场景。InnoDB具有优秀的数据完整性和可靠性，支持自动崩溃恢复和数据备份等功能。

与其他存储引擎相比，InnoDB还支持外键约束、异步提交、缓冲池和多版本并发控制（MVCC）等高级特性。InnoDB的性能优化也得到了持续的改善和增强，使其在处理大规模数据时表现出色。

MyISAM：快速的读取性能

MyISAM是另一个常用的MySQL存储引擎，其主要优点是快速的读取性能和简单的结构。MyISAM适用于读密集型的应用场景，比如数据仓库、报表生成等。

然而，MyISAM在写入操作和并发访问方面的性能相对较差。它使用表级锁定，在高并发的情况下容易出现性能瓶颈。此外，MyISAM不支持事务和崩溃恢复功能，因此不适合对数据一致性要求较高的应用。

MEMORY：内存存储引擎

MEMORY存储引擎是一个特殊的MySQL存储引擎，将数据保存在内存中，提供了非常快速的数据读写速度。它适用于需要频繁读写临时数据的应用，比如缓存、临时表等。

然而，由于数据存储在内存中，MEMORY存储引擎对内存的需求较高。如果内存不足，将导致性能下降或数据无法完全存储。此外，由于数据存在于内存中，如果发生数据库重启或服务器宕机，数据将丢失。

如何选择适合的存储引擎？

选择合适的MySQL存储引擎取决于应用的特性和需求。以下是一些建议：

如果应用需要支持事务和并发访问，推荐使用InnoDB存储引擎。
如果应用是读密集型，对数据一致性和事务支持要求不高，可以考虑使用MyISAM存储引擎。
如果应用需要频繁读写临时数据，可以选择MEMORY存储引擎。
如果应用需要兼顾读写性能和数据一致性，可以考虑使用其他存储引擎，如NDB Cluster、ARCHIVE等。

另外，需要注意的是，不同的存储引擎之间的特性和行为可能存在差异。在进行应用开发和数据库设计时，应充分了解和考虑所选存储引擎的特性，以获取最佳的数据库性能和数据管理效果。

总结

MySQL存储引擎是决定数据库数据存储和管理方式的核心组件。根据应用需求选择合适的存储引擎能够提升数据库性能、数据可靠性和数据一致性。

InnoDB适用于需要高并发读写和事务支持的应用，MyISAM适用于读密集型应用，MEMORY适用于频繁读写临时数据的应用。选择存储引擎需要结合具体场景和需求进行综合考虑，以达到最佳的数据库性能。

希望通过本文的介绍，读者能够对MySQL存储引擎有更深入的了解，为应用开发和数据库设计提供参考和指导。

八、mysql 存储引擎

MySQL存储引擎：了解不同引擎类型的优缺点

MySQL 是一种广泛使用的关系型数据库管理系统，其灵活性和可扩展性使得它成为了许多应用程序的首选。在 MySQL 中，存储引擎是一种负责管理数据的组件，它对于数据的存储、索引以及数据查询等操作起着至关重要的作用。本文将深入探讨 MySQL 中常见的存储引擎类型以及它们的优缺点。

InnoDB 引擎

InnoDB 是 MySQL 的默认存储引擎，它被广泛认可为企业级应用的首选。InnoDB 以其强大的事务支持功能和高并发性能而闻名。它支持行级锁定，实现了对数据的高度并发处理，可以满足大规模高并发的应用需求。此外，InnoDB 还具备实际的数据完整性保护机制，支持外键约束，可以确保数据的一致性和可靠性。

然而，InnoDB 也存在一些缺点。首先，它在处理大量写入操作时的性能略低于其他存储引擎，因为它需要保证数据的完整性和一致性。其次，InnoDB 对于处理大量的短期查询请求也相对较慢，因为每次查询都需要执行事务管理和锁定操作。

MyISAM 引擎

MyISAM 是 MySQL 中另一个常见的存储引擎类型。与 InnoDB 不同的是，MyISAM 引擎对于读密集型应用有着出色的优化性能。它可以在性能上比 InnoDB 更快，特别是在执行大量的 SELECT 查询时。此外，MyISAM 还支持全文索引，使得对于全文搜索的应用有着良好的支持。

然而，MyISAM 也有其局限性。首先，它不支持事务和行级锁定，这意味着在并发写入操作下可能存在数据完整性的问题。其次，MyISAM 对于大规模并发写入操作的性能较差，因为所有写入操作会对整个表进行锁定。

Memory 引擎

Memory 引擎是 MySQL 中专门用于处理内存表的存储引擎。它的数据完全存储在内存中，因此具备出色的读写性能。由于数据存储在内存中，Memory 引擎对于高速访问和查询具有绝对的优势。此外，内存表不会受到磁盘 I/O 操作的影响，因此在处理大量短期数据时非常高效。

然而，Memory 引擎也有一些限制。首先，由于数据存储在内存中，当服务器重启或崩溃时，所有数据都会丢失。其次，内存表的大小受到可用内存的限制，因此不适合存储大量数据。另外，在内存表中使用的索引类型也受到一定的限制。

其他存储引擎

除了上述三种常见的存储引擎外，MySQL 还支持其他一些存储引擎，如 CSV、Archive 和 Blackhole 等。这些存储引擎各有适用的场景和特点。

CSV 存储引擎将数据以逗号分隔的形式存储在文本文件中，适用于需要与其他系统交换数据的场景。然而，由于不支持索引，CSV 引擎在处理大量数据时性能较差。

Archive 存储引擎以追加的方式将数据存储在可压缩的文件中。它适合于存储大量的归档数据，但不支持索引和随机访问查询。

Blackhole 存储引擎会将所有写入操作都忽略，并将读操作发送到不同的 MySQL 服务器。它主要用于复制和分布式架构场景。

总结

对于选择合适的 MySQL 存储引擎，需要根据应用的特点和需求进行权衡。如果应用对数据完整性和并发性能要求较高，那么 InnoDB 引擎是一个不错的选择。如果应用主要是读密集型或全文搜索应用，那么 MyISAM 引擎会更加适合。而内存表的 Memory 引擎则适合处理大量短期数据。当然，根据特定的场景和需求，还可以考虑其他各种存储引擎。

希望本文对您在选择和使用 MySQL 存储引擎时有所帮助！

九、mysql workbench与mysql的区别？

MySQL是数据库

MySQL WorkBench是MySQL官方提供的MySQL管理软件.

你做网站设计,必须要的是mysql.而mysql workbench只是一个图形化的管理mysql的软件.

十、Mysql存储引擎InnoDB和Myisam的六大区别？

从 MySQL 5.7 开始，开发人员改变了 InnoDB 构建二级索引的方式，采用自下而上的方法，而不是早期版本中自上而下的方法了。在这篇文章中，我们将通过一个示例来说明如何构建 InnoDB 索引。最后，我将解释如何通过为 innodb_fill_factor 设置更合适的值。

索引构建过程

在有数据的表上构建索引，InnoDB 中有以下几个阶段：1.读取阶段（从聚簇索引读取并构建二级索引条目）2.合并排序阶段3.插入阶段（将排序记录插入二级索引）在 5.6 版本之前，MySQL 通过一次插入一条记录来构建二级索引。这是一种“自上而下”的方法。搜索插入位置从树的根部（顶部）开始并达到叶页（底部）。该记录插入光标指向的叶页上。在查找插入位置和进行业面拆分和合并方面开销很大。从MySQL 5.7开始，添加索引期间的插入阶段使用“排序索引构建”，也称为“批量索引加载”。在这种方法中，索引是“自下而上”构建的。即叶页（底部）首先构建，然后非叶级别直到根（顶部）。

示例

在这些情况下使用排序的索引构建：

ALTER TABLE t1 ADD INDEX（or CREATE INDEX）

ALTER TABLE t1 ADD FULLTEXT INDEX

ALTER TABLE t1 ADD COLUMN, ALGORITHM = INPLACE

OPIMIZE t1

对于最后两个用例，ALTER 会创建一个中间表。中间表索引（主要和次要）使用“排序索引构建”构建。

算法

在 0 级别创建页，还要为此页创建一个游标

使用 0 级别处的游标插入页面，直到填满

页面填满后，创建一个兄弟页（不要插入到兄弟页）

为当前的整页创建节点指针（子页中的最小键，子页码），并将节点指针插入上一级（父页）

在较高级别，检查游标是否已定位。如果没有，请为该级别创建父页和游标

在父页插入节点指针

如果父页已填满，请重复步骤 3, 4, 5, 6

现在插入兄弟页并使游标指向兄弟页

在所有插入的末尾，每个级别的游标指向最右边的页。提交所有游标（意味着提交修改页面的迷你事务，释放所有锁存器）

为简单起见，上述算法跳过了有关压缩页和 BLOB（外部存储的 BLOB）处理的细节。

通过自下而上的方式构建索引为简单起见，假设子页和非子页中允许的最大记录数为 3

CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c BLOB);

INSERT INTO t1 VALUES (1, 11, 'hello111');

INSERT INTO t1 VALUES (2, 22, 'hello222');

INSERT INTO t1 VALUES (3, 33, 'hello333');

INSERT INTO t1 VALUES (4, 44, 'hello444');

INSERT INTO t1 VALUES (5, 55, 'hello555');

INSERT INTO t1 VALUES (6, 66, 'hello666');

INSERT INTO t1 VALUES (7, 77, 'hello777');

INSERT INTO t1 VALUES (8, 88, 'hello888');

INSERT INTO t1 VALUES (9, 99, 'hello999');

INSERT INTO t1 VALUES (10, 1010, 'hello101010');

ALTER TABLE t1 ADD INDEX k1(b);

InnoDB 将主键字段追加到二级索引。二级索引 k1 的记录格式为(b, a)。在排序阶段完成后，记录为：

(11,1), (22,2), (33,3), (44,4), (55,5), (66,6), (77,7), (88,8), (99,9), (1010, 10)

初始插入阶段

让我们从记录 (11,1) 开始。

在 0 级别（叶级别）创建页

创建一个到页的游标

所有插入都将转到此页面，直到它填满了

箭头显示游标当前指向的位置。它目前位于第 5 页，下一个插入将转到此页面。

还有两个空闲插槽，因此插入记录 (22,2) 和 (33,3) 非常简单对于下一条记录 (44,4)，页码 5 已满（前面提到的假设最大记录数为 3）。这就是步骤。页填充时的索引构建

创建一个兄弟页，页码 6

不要插入兄弟页

在游标处提交页面，即迷你事务提交，释放锁存器等

作为提交的一部分，创建节点指针并将其插入到【当前级别 + 1】的父页面中（即在 1 级别）

节点指针的格式 (子页面中的最小键,子页码) 。第 5 页的最小键是 (11,1) 。在父级别插入记录 ((11,1)，5)。

1 级别的父页尚不存在，MySQL 创建页码 7 和指向页码 7 的游标。

将 ((11,1)，5) 插入第 7 页

现在，返回到 0 级并创建从第 5 页到第 6 页的链接，反之亦然

0 级别的游标现在指向兄弟页，页码为 6

将 (44,4) 插入第 6 页

下一个插入 - (55,5) 和 (66,6) - 很简单，它们转到第 6 页。

插入记录 (77,7) 类似于 (44,4)，除了父页面（页面编号 7）已经存在并且它有两个以上记录的空间。首先将节点指针 ((44,4),8) 插入第 7 页，然后将 (77,7) 记录到同级 8 页中。

插入记录 (88,8) 和 (99,9) 很简单，因为第 8 页有两个空闲插槽。

下一个插入 (1010,10) 。将节点指针 ((77,7),8) 插入 1级别的父页（页码 7）。MySQL 在 0 级创建同级页码 9。将记录 (1010,10) 插入第 9 页并将光标更改为此页面。以此类推。在上面的示例中，数据库在 0 级别提交到第 9 页，在 1 级别提交到第 7 页。

我们现在有了一个完整的 B+-tree 索引，它是自下至上构建的！

索引填充因子全局变量 innodb_fill_factor 用于设置插入 B-tree 页中的空间量。默认值为 100，表示使用整个业面（不包括页眉）。聚簇索引具有 innodb_fill_factor=100 的免除项。在这种情况下，聚簇索引也空间的 1 /16 保持空闲。即 6.25% 的空间用于未来的 DML。

值 80 意味着 MySQL 使用了 80% 的页空间填充，预留 20% 于未来的更新。如果 innodb_fill_factor=100 则没有剩余空间供未来插入二级索引。如果在添加索引后，期望表上有更多的 DML，则可能导致业面拆分并再次合并。在这种情况下，建议使用 80-90 之间的值。此变量还会影响使用 OPTIMIZE TABLE 和 ALTER TABLE DROP COLUMN, ALGOITHM=INPLACE 重新创建的索引。也不应该设置太低的值，例如低于 50。因为索引会占用浪费更多的磁盘空间，值较低时，索引中的页数较多，索引统计信息的采样可能不是最佳的。优化器可以选择具有次优统计信息的错误查询计划。

排序索引构建的优点

没有页面拆分（不包括压缩表）和合并

没有重复搜索插入位置

插入不会被重做记录（页分配除外），因此重做日志子系统的压力较小

缺点

ALTER 正在进行时，插入性能降低 Bug＃82940，但在后续版本中计划修复。

顶一下

(0)

踩一下

(0)

相关评论

我要评论