精华内容
下载资源
问答
  • mysql存储引擎

    万次阅读 多人点赞 2019-07-31 19:28:44
    数据库存储引擎 数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还...

    数据库存储引擎

    数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还可以获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。

    因为在关系数据库中数据的存储是以表的形式存储的,所以存储引擎也可以称为表类型(Table Type,即存储和操作此表的类型)。

    如创建一个InnoDB类型的表:

    CREATE TABLE `brand` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `brand_name` varchar(64) NOT NULL,
      `brand_logo` varchar(255) NOT NULL,
      `description` varchar(255) NOT NULL,
      `parent_id` int(11) NOT NULL,
      `layer` int(11) NOT NULL DEFAULT '0',
      `enabled` int(11) NOT NULL DEFAULT '0',
      `path` varchar(255) DEFAULT NULL,
      PRIMARY KEY (`id`),
      UNIQUE KEY `brand_name` (`brand_name`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

    mysql存储引擎

    MySQL给开发者提供了查询存储引擎的功能,执行以下sql即可查询到mysql中的存储引擎

    SHOW ENGINES

    我的mysql版本是5.7.22,下面是在Navicat中执行的结果

    InnoDB存储引擎

    InnoDB是事务型数据库的首选引擎,通过上图也看到了,InnoDB是目前MYSQL的默认事务型引擎,是目前最重要、使用最广泛的存储引擎。支持事务安全表(ACID),支持行锁定和外键。InnoDB主要特性有:

    1、InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事物安全(ACID兼容)存储引擎。InnoDB锁定在行级并且也在SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中,可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来,甚至在同一个查询中也可以混合

    2、InnoDB是为处理巨大数据量的最大性能设计。它的CPU效率可能是任何其他基于磁盘的关系型数据库引擎锁不能匹敌的

    3、InnoDB存储引擎完全与MySQL服务器整合,InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB将它的表和索引在一个逻辑表空间中,表空间可以包含数个文件(或原始磁盘文件)。这与MyISAM表不同,比如在MyISAM表中每个表被存放在分离的文件中。InnoDB表可以是任何尺寸,即使在文件尺寸被限制为2GB的操作系统上

    4、InnoDB支持外键完整性约束,存储表中的数据时,每张表的存储都按主键顺序存放,如果没有显示在表定义时指定主键,InnoDB会为每一行生成一个6字节的ROWID,并以此作为主键

    5、InnoDB被用在众多需要高性能的大型数据库站点上

    InnoDB不创建目录,使用InnoDB时,MySQL将在MySQL数据目录下创建一个名为ibdata1的10MB大小的自动扩展数据文件,以及两个名为ib_logfile0和ib_logfile1的5MB大小的日志文件。

    场景:由于其支持事务处理,支持外键,支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高(比如银行),要求实现并发控制(比如售票),那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库,也可以选择InnoDB,因为支持事务的提交(commit)和回滚(rollback)。

    MyISAM存储引擎

    MyISAM基于ISAM存储引擎,并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度,但不支持事物和外键。

    MyISAM主要特性有:

    1、大文件(达到63位文件长度)在支持大文件的文件系统和操作系统上被支持

    2、当把删除和更新及插入操作混合使用的时候,动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块,以及若下一个块被删除,就扩展到下一块自动完成

    3、每个MyISAM表最大索引数是64,这可以通过重新编译来改变。每个索引最大的列数是16

    4、最大的键长度是1000字节,这也可以通过编译来改变,对于键长度超过250字节的情况,一个超过1024字节的键将被用上

    5、BLOB和TEXT列可以被索引,支持FULLTEXT类型的索引,而InnoDB不支持这种类型的索引

    6、NULL被允许在索引的列中,这个值占每个键的0~1个字节

    7、所有数字键值以高字节优先被存储以允许一个更高的索引压缩

    8、每个MyISAM类型的表都有一个AUTO_INCREMENT的内部列,当INSERT和UPDATE操作的时候该列被更新,同时AUTO_INCREMENT列将被刷新。所以说,MyISAM类型表的AUTO_INCREMENT列更新比InnoDB类型的AUTO_INCREMENT更快

    9、可以把数据文件和索引文件放在不同目录

    10、每个字符列可以有不同的字符集

    11、有VARCHAR的表可以固定或动态记录长度

    12、VARCHAR和CHAR列可以多达64KB

    存储格式:

    1、静态表(默认):字段都是非变长的(每个记录都是固定长度的)。存储非常迅速、容易缓存,出现故障容易恢复;占用空间通常比动态表多。

    2、动态表:占用的空间相对较少,但是频繁的更新删除记录会产生碎片,需要定期执行optimize table或myisamchk -r命令来改善性能,而且出现故障的时候恢复比较困难。

    3、压缩表:使用myisampack工具创建,占用非常小的磁盘空间。因为每个记录是被单独压缩的,所以只有非常小的访问开支。

    静态表的数据在存储的时候会按照列的宽度定义补足空格,在返回数据给应用之前去掉这些空格。如果需要保存的内容后面本来就有空格,在返回结果的时候也会被去掉。(其实是数据类型char的行为,动态表中若有这个数据类型也同样会有这个问题)

    使用MyISAM引擎创建数据库,将产生3个文件。文件的名字以表名字开始,扩展名之处文件类型:frm文件存储表定义、数据文件的扩展名为.MYD(MYData)、索引文件的扩展名时.MYI(MYIndex)。

    场景:如果表主要是用于插入新记录和读出记录,那么选择MyISAM能实现处理高效率。

    MERGE存储引擎

    MERGE存储引擎是一组MyISAM表的组合,这些MyISAM表结构必须完全相同,尽管其使用不如其它引擎突出,但是在某些情况下非常有用。说白了,Merge表就是几个相同MyISAM表的聚合器;Merge表中并没有数据,对Merge类型的表可以进行查询、更新、删除操作,这些操作实际上是对内部的MyISAM表进行操作。

    场景:对于服务器日志这种信息,一般常用的存储策略是将数据分成很多表,每个名称与特定的时间端相关。例如:可以用12个相同的表来存储服务器日志数据,每个表用对应各个月份的名字来命名。当有必要基于所有12个日志表的数据来生成报表,这意味着需要编写并更新多表查询,以反映这些表中的信息。与其编写这些可能出现错误的查询,不如将这些表合并起来使用一条查询,之后再删除Merge表,而不影响原来的数据,删除Merge表只是删除Merge表的定义,对内部的表没有任何影响。

    MEMORY存储引擎

    MEMORY存储引擎将表中的数据存储到内存中,未查询和引用其他表数据提供快速访问。MEMORY主要特性有:

    1、MEMORY表的每个表可以有多达32个索引,每个索引16列,以及500字节的最大键长度

    2、MEMORY存储引擎执行HASH和BTREE缩影

    3、可以在一个MEMORY表中有非唯一键值

    4、MEMORY表使用一个固定的记录长度格式

    5、MEMORY不支持BLOB或TEXT列

    6、MEMORY支持AUTO_INCREMENT列和对可包含NULL值的列的索引

    7、MEMORY表在所由客户端之间共享(就像其他任何非TEMPORARY表)

    8、MEMORY表内存被存储在内存中,内存是MEMORY表和服务器在查询处理时的空闲中,创建的内部表共享

    9、当不再需要MEMORY表的内容时,要释放被MEMORY表使用的内存,应该执行DELETE FROM或TRUNCATE TABLE,或者删除整个表(使用DROP TABLE)

    MEMORY存储引擎默认使用哈希(HASH)索引,其速度比使用B-+Tree型要快,但也可以使用B树型索引。由于这种存储引擎所存储的数据保存在内存中,所以其保存的数据具有不稳定性,比如如果mysqld进程发生异常、重启或计算机关机等等都会造成这些数据的消失,所以这种存储引擎中的表的生命周期很短,一般只使用一次。现在mongodb、redis等NOSQL数据库愈发流行,MEMORY存储引擎的使用场景越来越少。

    场景:如果需要该数据库中一个用于查询的临时表。

    ARCHIVE存储引擎

    Archive是归档的意思,在归档之后很多的高级功能就不再支持了,仅仅支持最基本的插入和查询两种功能。在MySQL 5.5版以前,Archive是不支持索引,但是在MySQL 5.5以后的版本中就开始支持索引了。Archive拥有很好的压缩机制,它使用zlib压缩库,在记录被请求时会实时压缩,所以它经常被用来当做仓库使用。

    场景:由于高压缩和快速插入的特点Archive非常适合作为日志表的存储引擎,但是前提是不经常对该表进行查询操作。

    CSV存储引擎

    使用该引擎的MySQL数据库表会在MySQL安装目录data文件夹中的和该表所在数据库名相同的目录中生成一个.CSV文件(所以,它可以将CSV类型的文件当做表进行处理),这种文件是一种普通文本文件,每个数据行占用一个文本行。该种类型的存储引擎不支持索引,即使用该种类型的表没有主键列;另外也不允许表中的字段为null。csv的编码转换需要格外注意。

    场景:这种引擎支持从数据库中拷入/拷出CSV文件。如果从电子表格软件输出一个CSV文件,将其存放在MySQL服务器的数据目录中,服务器就能够马上读取相关的CSV文件。同样,如果写数据库到一个CSV表,外部程序也可以立刻读取它。在实现某种类型的日志记录时,CSV表作为一种数据交换格式,特别有用。

    BLACKHOLE存储引擎(黑洞引擎)

    该存储引擎支持事务,而且支持mvcc的行级锁,写入这种引擎表中的任何数据都会消失,主要用于做日志记录或同步归档的中继存储,这个存储引擎除非有特别目的,否则不适合使用。

    场景:如果配置一主多从的话,多个从服务器会在主服务器上分别开启自己相对应的线程,执行binlogdump命令而且多个此类进程并不是共享的。为了避免因多个从服务器同时请求同样的事件而导致主机资源耗尽,可以单独建立一个伪的从服务器或者叫分发服务器。

    PERFORMANCE_SCHEMA存储引擎

    该引擎主要用于收集数据库服务器性能参数。这种引擎提供以下功能:提供进程等待的详细信息,包括锁、互斥变量、文件信息;保存历史的事件汇总信息,为提供MySQL服务器性能做出详细的判断;对于新增和删除监控事件点都非常容易,并可以随意改变mysql服务器的监控周期,例如(CYCLE、MICROSECOND)。 MySQL用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表。

    场景: DBA能够较明细得了解性能降低可能是由于哪些瓶颈。

    Federated存储引擎

    该存储引擎可以不同的Mysql服务器联合起来,逻辑上组成一个完整的数据库。这种存储引擎非常适合数据库分布式应用。

    Federated存储引擎可以使你在本地数据库中访问远程数据库中的数据,针对federated存储引擎表的查询会被发送到远程数据库的表上执行,本地是不存储任何数据的。

    缺点:

    1.对本地虚拟表的结构修改,并不会修改远程表的结构

    2.truncate 命令,会清除远程表数据

    3. drop命令只会删除虚拟表,并不会删除远程表

    4.不支持 alter table 命令

    5. select count(*), select * from limit M, N 等语句执行效率非常低,数据量较大时存在很严重的问题,但是按主键或索引列查询,则很快,如以下查询就非常慢(假设 id 为主索引)

    select id from db.tablea where id >100 limit 10 ;

    而以下查询就很快:

    select id from db.tablea where id >100 and id<150

    6.  如果虚拟虚拟表中字段未建立索引,而实体表中为此字段建立了索引,此种情况下,性能也相当差。但是当给虚拟表建立索引后,性能恢复正常。

    7. 类似 where name like "str%" limit 1 的查询,即使在 name 列上创建了索引,也会导致查询过慢,是因为federated引擎会将所有满足条件的记录读取到本地,再进行 limit 处理。

    场景: dblink。

    存储引擎的选择

    功 能

    MYISAM

    Memory

    InnoDB

    Archive

    存储限制

    256TB

    RAM

    64TB

    None

    支持事物

    No

    No

    Yes

    No

    支持全文索引

    Yes

    No

    No

    No

    支持数索引

    Yes

    Yes

    Yes

    No

    支持哈希索引

    No

    Yes

    No

    No

    支持数据缓存

    No

    N/A

    Yes

    No

    支持外键

    No

    No

    Yes

    No

     

    展开全文
  • 存储引擎

    千次阅读 2020-01-13 15:35:49
    存储引擎概述 作为可插拔式的组件提供 MySQL服务软件自带的功能程序,处理表的处理器 不同的存储引擎有不同的功能和数据存储方式 相关 查看可用的存储引擎: mysql> show engines; 查看表的存储...

    存储引擎概述

    作为可插拔式的组件提供

    • MySQL服务软件自带的功能程序,处理表的处理器
    • 不同的存储引擎有不同的功能和数据存储方式

    相关

    • 查看可用的存储引擎:
    mysql> show engines;
    
    • 查看表的存储引擎:(建表时不指定存储引擎则使用默认引擎)
    mysql> show create table 表名; #查看表的创建命令(包含引擎信息)
    
    • 修改默认储存引擎:
    ] vim /etc/my.cnf
    default-storage-engine="引擎名"
    
    • 建表时指定存储引擎:
    mysql> create table 表(字段...)engine="引擎名";
    
    • 修改表的存储引擎:
    mysql> alter table 表名 engine=引擎名;
    

    存储引擎

    工作中常用存储引擎:innodb/myisam

    • 读操作多的表适合使用MyISAM:节省系统硬件资源
    • 写操作多的表适合使用innodb:并发访问量大

    存储引擎特点

    • MyISAM

      • 表文件:
      1. .frm 表结构
      2. .MYI 索引
      3. .MYD 表数据
      • 主要特点:
      1. 支持表级锁
      2. 不支持事务、事务回滚、外键
    • InnoDB

      • 表文件:
      1. .frm 表结构
      2. .ibd 表空间(表索引+表记录)
      • 主要特点:
      1. 支持行级锁
      2. 支持事务、回滚、外键
      • 事务日志文件:
      1. ibdata1
      2. ib_logfile0
      3. ib_logfile1

    锁表:对表执行命令时,锁定表或行,命令执行期间限制其他用户对锁定的数据进行操作

    锁级别 说明
    表级锁 访问时整张表锁表
    行级锁 访问时只锁定被访问的行,其余未加锁的行可以被访问
    锁类型 触发锁的SQL命令
    读锁(共享锁) select
    写锁(排他锁/互斥锁) insert/update/delete
    • 共享锁:一个select期间,可以同时再次select,不可以update/delete/insert
    • 排他锁/互斥锁:一个update/delete/insert期间,不可以执行select,也不可以update/delete/insert
    mysql> show status like 'table_lock%'; #查看当前锁状态
    

    事务特性:(ACID)

    1. Atomic:原子性
      事务的整个操作是一个整体,不可分割,要么全部成功,要么全部失败
    2. Consistemcy:一致性
      事务操作的前后,表中的记录没有变化
    3. Isolation:隔离性
      事务操作时相互隔离不受影响的
    4. Durability:持久性
      数据一旦提交,不可改变,永久改变表数据
    mysql> show variables like 'autocommit'; #查看提交状态
    mysql> set autocommit=off; #关闭自动提交(仅当前有效)
    mysql> rollback; #数据回滚
    mysql> commit; #提交数据
    
    展开全文
  • mysql手册07_存储引擎

    万次阅读 2020-08-15 17:30:45
    mysql手册07_存储引擎 存储引擎其实就是对于数据库文件的一种存取机制,实现存储数据,建立索引,以及更新和查询数据等技术的方式。 存储引擎是建立在 数据表 层面上的,同一数据库的不同表可以建立不同的存储引擎...

    mysql手册07_存储引擎


    存储引擎其实就是对于数据库文件的一种存取机制,实现存储数据建立索引,以及更新和查询数据等技术的方式。
    存储引擎是建立在 数据表 层面上的,同一数据库的不同表可以建立不同的存储引擎。

    查看支持的存储引擎:
    show engines;
    
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    | Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    | MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
    | MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
    | CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
    | FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
    | PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
    | MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
    | InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
    | BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
    | ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    
    由表可知 mysql的默认存储引擎InnoDB支持事务、行级锁和外键。
    
    查看数据库默认的存储引擎:
    show variables like '%storage_engine%';
    +---------------------------------+-----------+
    | Variable_name                   | Value     |
    +---------------------------------+-----------+
    | default_storage_engine          | InnoDB    |
    | default_tmp_storage_engine      | InnoDB    |
    | disabled_storage_engines        |           |
    | internal_tmp_mem_storage_engine | TempTable |
    +---------------------------------+-----------+
    

    存储引擎的特性:

    特点 InnoDB(默认) MyISAM(5.5之前的默认存储引擎) Memory
    事务安全 支持 X X
    锁机制 行锁(适合高并发) 表锁 表锁
    支持外键 支持 X X
    存储限制 64TB
    B树索引 支持 支持 支持
    哈希索引 X X 支持
    全文索引 支持(5.6版本之后) 支持
    集群索引 支持 X
    数据索引 支持 X
    索引缓存 支持 支持
    数据可压缩 X 支持
    空间使用
    内存使用
    批量插入速度

    存储引擎的选择:

    InnoDB引擎支持事务、支持外键行级锁。适合对数据准确性要求较高的系统

    MyISAM引擎 适合读取和插入多更新和删除少,对事务完整性、并发性要求低的数据表

    MEMORY引擎 的表结构存储在磁盘中,但数据文件存储在内存中,有利于数据的快速处理。缺点是无法存储过大的表,且重启或者关机会清除数据。适合更新频率不大的小表

    展开全文
  • 哈希存储引擎 B树存储引擎 LSM树存储引擎 并发控制 存储快照实现原理

    哈希存储引擎

    哈希存储引擎哈希表的持久化实现,支持增、删、改以及随机读取操作,但不支持顺序扫描,对应的存储系统为key-value存储系统。对于key-value的插入以及查询,哈希表的复杂度都是O(1),明显比树的操作O(n)快,如果不需要有序的遍历数据,哈希表就非常适合。代表性的数据库有:Redis,Memcache,以及存储系统Bitcask。
    Bitcask是一个基于哈希表结构的键值存储系统,它仅支持追加操作(Append-only),所有的写操作只追加不修改老的数据。每个文件有一定的大小限制,当文件增加到相应大小,就会产生一个新文件,老的文件只读不写。在任意时刻,只有一个文件是可写的,用于数据追加,称为活跃文件,而其他已经达到大小限制的文件,称为老数据文件。

    数据结构


    Bitcask数据文件中的数据是一条一条写入操作,记录包含,key,value,主键长度,value长度,时间戳(timestamp)以及crc校验值。(删除操作不会删除旧的条目,而是将value设定为一个特殊的标识值)。
    内存中采用基于哈希表的索引数据结构,哈希表的作用是通过主键快速地定位到value的位置。哈希表结构中的每一项包含了三个用于定位数据的信息,分别是文件编号(file id),value在文件中的位置(value_pos),value长度(value_sz),通过读取file_id对应文件的value_pos开始的value_sz个字节,这就得到了最终的value值。写入时首先将Key-Value记录追加到活跃数据文件的末尾,接着更新内存哈希表,因此,每个写操作总共需要进行一次顺序的磁盘写入和一次内存操作。
    Bitcask在内存中存储了主键和value的索引信息,磁盘文件中存储了主键和value的实际内容。系统基于一个假设,value的长度远大于主键的长度。假如value的平均长度为1KB,每条记录在内存中的索引信息为32字节,那么,磁盘内存比为32 : 1。这样,32GB内存索引的数据量为32GB×32 = 1TB。

    定期合并

    Bitcask系统中的记录删除或者更新后,原来的记录成为垃圾数据。如果这些数据一直保存下去,文件会无限膨胀下去,为了解决这个问题,Bitcask需要定期执行合并(Compaction)操作以实现垃圾回收。所谓合并操作,即将所有老数据文件中的数据扫描一遍并生成新的数据文件,这里的合并其实就是对同一个key的多个操作以只保留最新一个的原则进行删除,每次合并后,新生成的数据文件就不再有冗余数据了。

    快速恢复

    Bitcask系统中的哈希索引存储在内存中,如果不做额外的工作,服务器断电重启重建哈希表需要扫描一遍数据文件,如果数据文件很大,这是一个非常耗时的过程。Bitcask通过索引文件(hint file)来提高重建哈希表的速度。
    简单来说,索引文件就是将内存中的哈希索引表转储到磁盘生成的结果文件。Bitcask对老数据文件进行合并操作时,会产生新的数据文件,这个过程中还会产生一个索引文件,这个索引文件记录每一条记录的哈希索引信息。与数据文件不同的是,索引文件并不存储具体的value值,只存储value的位置(与内存哈希表一样)。这样,在重建哈希表时,就不需要扫描所有数据文件,而仅仅需要将索引文件中的数据一行行读取并重建即可,大大减少了重启后的恢复时间。

    B树存储引擎

    相比哈希存储引擎,B树存储引擎不仅支持随机读取,还支持范围扫描。关系数据库中通过索引访问数据,在Mysql InnoDB中,有一个称为聚集索引的特殊索引,行的数据存于其中,组织成B+树(B树的一种)数据结构。

    1.数据结构


    如图所示,MySQL InnoDB按照页面(Page)来组织数据,每个页面对应B+树的一个节点。其中,叶子节点保存每行的完整数据,非叶子节点保存索引信息。数据在每个节点中有序存储,数据库查询时需要从根节点开始二分查找直到叶子节点,每次读取一个节点,如果对应的页面不在内存中,需要从磁盘中读取并缓存起来。B+树的根节点是常驻内存的,因此,B+树一次检索最多需要h-1次磁盘IO,复杂度为O(h)=O(logdN)(N为元素个数,d为每个节点的出度,h为B+树高度)。修改操作首先需要记录提交日志,接着修改内存中的B+树。如果内存中的被修改过的页面超过一定的比率,后台线程会将这些页面刷到磁盘中持久化。

    2.缓冲区管理

    缓冲区管理器负责将可用的内存划分成缓冲区,缓冲区是与页面同等大小的区域,磁盘块的内容可以传送到缓冲区中。缓冲区管理器的关键在于替换策略,即选择将哪些页面淘汰出缓冲池。常见的算法有以下两种。

    (1)LRU

    LRU算法淘汰最长时间没有读或者写过的块。这种方法要求缓冲区管理器按照页面最后一次被访问的时间组成一个链表,每次淘汰链表尾部的页面。直觉上,长时间没有读写的页面比那些最近访问过的页面有更小的最近访问的可能性。

    (2)LIRS

    LRU算法在大多数情况下表现是不错的,但有一个问题:假如某一个查询做了一次全表扫描,将导致缓冲池中的大量页面(可能包含很多很快被访问的热点页面)被替换,从而污染缓冲池。现代数据库一般采用LIRS算法,将缓冲池分为两级,数据首先进入第一级,如果数据在较短的时间内被访问两次或者以上,则成为热点数据进入第二级,每一级内部还是采用LRU替换算法。Oracle数据库中的Touch Count算法和MySQL InnoDB中的替换算法都采用了类似的分级思想。以MySQL InnoDB为例,InnoDB内部的LRU链表分为两部分:新子链表(new sublist)和老子链表(old sublist),默认情况下,前者占5/8,后者占3/8。页面首先插入到老子链表,InnoDB要求页面在老子链表停留时间超过一定值,比如1秒,才有可能被转移到新子链表。当出现全表扫描时,InnoDB将数据页面载入到老子链表,由于数据页面在老子链表中的停留时间不够,不会被转移到新子链表中,这就避免了新子链表中的页面被替换出去的情况。

    插入(insert)操作

    插入一个元素时,首先在B树中是否存在,如果不存在,即在叶子结点处结束,然后在叶子结点中插入该新的元素,注意:如果叶子结点空间足够,这里需要向右移动该叶子结点中大于新插入关键字的元素,如果空间满了以致没有足够的空间去添加新的元素,则将该结点进行“分裂”,将一半数量的关键字元素分裂到新的其相邻右结点中,中间关键字元素上移到父结点中(当然,如果父结点空间满了,也同样需要“分裂”操作),而且当结点中关键元素向右移动了,相关的指针也需要向右移。如果在根结点插入新元素,空间满了,则进行分裂操作,这样原来的根结点中的中间关键字元素向上移动到新的根结点中,因此导致树的高度增加一层。如下图所示:

    1、OK,下面咱们通过一个实例来逐步讲解下。插入以下字符字母到一棵空的树中(非根结点关键字数小了(小于2个)就合并,大了(超过4个)就分裂):C N G A H E K Q M F W L T Z D P R X Y S,首先,结点空间足够,4个字母插入相同的结点中,如下图:

    2、当咱们试着插入H时,结点发现空间不够,以致将其分裂成2个结点,移动中间元素G上移到新的根结点中,在实现过程中,咱们把AC留在当前结点中,而HN放置新的其右邻居结点中。如下图:

    3、当咱们插入E,K,Q时,不需要任何分裂操作

    4、插入M需要一次分裂,注意M恰好是中间关键字元素,以致向上移到父节点中

    5、插入F,W,L,T不需要任何分裂操作

    6、插入Z时,最右的叶子结点空间满了,需要进行分裂操作,中间元素T上移到父节点中,注意通过上移中间元素,树最终还是保持平衡,分裂结果的结点存在2个关键字元素。

    7、插入D时,导致最左边的叶子结点被分裂,D恰好也是中间元素,上移到父节点中,然后字母P,R,X,Y陆续插入不需要任何分裂操作(别忘了,树中至多5个孩子)。

    8、最后,当插入S时,含有N,P,Q,R的结点需要分裂,把中间元素Q上移到父节点中,但是情况来了,父节点中空间已经满了,所以也要进行分裂,将父节点中的中间元素M上移到新形成的根结点中,注意以前在父节点中的第三个指针在修改后包括DG节点中。这样具体插入操作的完成,下面介绍删除操作,删除操作相对于插入操作要考虑的情况多点。


    删除(delete)操作

    首先查找B树中需删除的元素,如果该元素在B树中存在,则将该元素在其结点中进行删除,如果删除该元素后,首先判断该元素是否有左右孩子结点,如果有,则上移孩子结点中的某相近元素(“左孩子最右边的节点”“右孩子最左边的节点”)到父节点中,然后移动之后情况;如果没有,直接删除后,移动之后的情况
    删除元素,移动相应元素之后,如果某结点中元素数目(即关键字数)小于ceil(m/2)-1,则需要看其某相邻兄弟结点是否丰满(结点中元素个数大于ceil(m/2)-1)(还记得第一节中关于B树的第5个特性中的c点么?: c)除根结点之外的结点(包括叶子结点)的关键字的个数n必须满足: (ceil(m / 2)-1)<= n <= m-1。m表示最多含有m个孩子,n表示关键字数。在本小节中举的一颗B树的示例中,关键字数n满足:2<=n<=4),如果丰满,则向父节点借一个元素来满足条件;如果其相邻兄弟都刚脱贫,即借了之后其结点数目小于ceil(m/2)-1,则该结点与其相邻的某一兄弟结点进行合并”成一个结点,以此来满足条件。那咱们通过下面实例来详细了解吧。
    以上述插入操作构造的一棵5阶B树(树中最多含有m(m=5)个孩子,因此关键字数最小为ceil(m / 2)-1=2。还是这句话,关键字数小了(小于2个)就合并,大了(超过4个)就分裂)为例,依次删除H,T,R,E


    1、首先删除元素H,当然首先查找HH在一个叶子结点中,且该叶子结点元素数目3大于最小元素数目ceil(m/2)-1=2,则操作很简单,咱们只需要移动K至原来H的位置,移动LK的位置(也就是结点中删除元素后面的元素向前移动)

    2、下一步,删除T,因为T没有在叶子结点中,而是在中间结点中找到,咱们发现他的继承者W(字母升序的下个元素),将W上移到T的位置,然后将原包含W的孩子结点中的W进行删除,这里恰好删除W后,该孩子结点中元素个数大于2,无需进行合并操作。

    3、下一步删除RR在叶子结点中,但是该结点中元素数目为2,删除导致只有1个元素,已经小于最小元素数目ceil(5/2)-1=2,而由前面我们已经知道:如果其某个相邻兄弟结点中比较丰满(元素个数大于ceil(5/2)-1=2),则可以向父结点借一个元素,然后将最丰满的相邻兄弟结点中上移最后或最前一个元素到父节点中(有没有看到红黑树中左旋操作的影子?),在这个实例中,右相邻兄弟结点中比较丰满(3个元素大于2),所以先向父节点借一个元素W下移到该叶子结点中,代替原来S的位置,S前移;然后X在相邻右兄弟结点中上移到父结点中,最后在相邻右兄弟结点中删除X,后面元素前移。

    4、最后一步删除E, 删除后会导致很多问题,因为E所在的结点数目刚好达标,刚好满足最小元素个数(ceil(5/2)-1=2),而相邻的兄弟结点也是同样的情况,删除一个元素都不能满足条件,所以需要该节点与某相邻兄弟结点进行合并操作;首先移动父结点中的元素(该元素在两个需要合并的两个结点元素之间)下移到其子结点中,然后将这两个结点进行合并成一个结点。所以在该实例中,咱们首先将父节点中的元素D下移到已经删除E而只有F的结点中,然后将含有DF的结点和含有A,C的相邻兄弟结点进行合并成一个结点。

    5、也许你认为这样删除操作已经结束了,其实不然,在看看上图,对于这种特殊情况,你立即会发现父节点只包含一个元素G,没达标(因为非根节点包括叶子结点的关键字数n必须满足于2=<n<=4,而此处的n=1),这是不能够接受的。如果这个问题结点的相邻兄弟比较丰满,则可以向父结点借一个元素。假设这时右兄弟结点(含有Q,X)有一个以上的元素(Q右边还有元素),然后咱们将M下移到元素很少的子结点中,将Q上移到M的位置,这时,Q的左子树将变成M的右子树,也就是含有NP结点被依附在M的右指针上。所以在这个实例中,咱们没有办法去借一个元素,只能与兄弟结点进行合并成一个结点,而根结点中的唯一元素M下移到子结点,这样,树的高度减少一层。
    为了进一步详细讨论删除的情况,再举另外一个实例
    这里是一棵不同的5B树,那咱们试着删除C

    于是将删除元素C的右子结点中的D元素上移到C的位置,但是出现上移元素后,只有一个元素的结点的情况。
    又因为含有E的结点,其相邻兄弟结点才刚脱贫(最少元素个数为2),不可能向父节点借元素,所以只能进行合并操作,于是这里将含有A,B的左兄弟结点和含有E的结点进行合并成一个结点。

    这样又出现只含有一个元素F结点的情况,这时,其相邻的兄弟结点是丰满的(元素个数为3>最小元素个数2),这样就可以想父结点借元素了,把父结点中的J下移到该结点中,相应的如果结点中J后有元素则前移,然后相邻兄弟结点中的第一个元素(或者最后一个元素)上移到父节点中,后面的元素(或者前面的元素)前移(或者后移);注意含有KL的结点以前依附在M的左边,现在变为依附在J的右边。这样每个结点都满足B树结构性质。

    从以上操作可看出:除根结点之外的结点(包括叶子结点)的关键字的个数n满足:(ceil(m / 2)-1)<= n <= m-1,即2<=n<=4。这也佐证了咱们之前的观点。删除操作完。

    LSM树存储引擎

    LSM树(Log Structured Merge Tree)的思想非常朴素,就是将对数据的修改增量保持在内存中,达到指定的大小限制后将这些修改操作批量写入磁盘,读取时需要合并磁盘中的历史数据和内存中最近的修改操作。LSM树的优势在于有效地规避了磁盘随机写入问题,但读取时可能需要访问较多的磁盘文件。

    1.存储结构


    如图2-8所示,LevelDB存储引擎主要包括:内存中的MemTable和不可变MemTable(Immutable MemTable,也称为Frozen MemTable,即冻结MemTable)以及磁盘上的几种主要文件:当前(Current)文件、清单(Manifest)文件、操作日志(Commit Log,也称为提交日志)文件以及SSTable文件。当应用写入一条记录时,LevelDB会首先将修改操作写入到操作日志文件,成功后再将修改操作应用到MemTable,这样就完成了写入操作。
    当MemTable占用的内存达到一个上限值后,需要将内存的数据转储到外存文件中。LevelDB会将原先的MemTable冻结成为不可变MemTable,并生成一个新的MemTable。新到来的数据被记入新的操作日志文件和新生成的MemTable中。顾名思义,不可变 MemTable的内容是不可更改的,只能读取不能写入或者删除。LevelDB后台线程会将不可变MemTable的数据排序后转储到磁盘,形成一个新的SSTable文件,这个操作称为Compaction。SSTable文件是内存中的数据不断进行Compaction操作后形成的,且SSTable的所有文件是一种层级结构,第0层为Level 0,第1层为Level 1,以此类推。
    SSTable中的文件是按照记录的主键排序的,每个文件有最小的主键和最大的主键。LevelDB的清单文件记录了这些元数据,包括属于哪个层级、文件名称、最小主键和最大主键。当前文件记录了当前使用的清单文件名。在LevelDB的运行过程中,随着Compaction的进行,SSTable文件会发生变化,新的文件会产生,老的文件被废弃,此时往往会生成新的清单文件来记载这种变化,而当前文件则用来指出哪个清单文件才是当前有效的。
    直观上,LevelDB每次查询都需要从老到新读取每个层级的SSTable文件以及内存中的MemTable。LevelDB做了一个优化,由于LevelDB对外只支持随机读取单条记录,查询时LevelDB首先会去查看内存中的MemTable,如果MemTable包含记录的主键及其对应的值,则返回记录即可;如果MemTable没有读到该主键,则接下来到同样处于内存中的不可变Memtable中去读取;类似地,如果还是没有读到,只能依次从新到老读取磁盘中的SSTable文件。

    WAL: Write-Ahead Logging

    在设计数据库的时候经常被使用,当插入一条数据时,数据先顺序写入 WAL 文件中,之后插入到内存中的 MemTable 中。这样就保证了数据的持久化,不会丢失数据,并且都是顺序写,速度很快。当程序挂掉重启时,可以从 WAL 文件中重新恢复内存中的

    MemTable

    MemTable 对应的就是 WAL 文件,是该文件内容在内存中的存储结构,通常用 SkipList 来实现。MemTable 提供了 k-v 数据的写入、删除以及读取的操作接口。其内部将 k-v 对按照 key 值有序存储,这样方便之后快速序列化到 SSTable 文件中,仍然保持数据的有序性。

    Immutable Memtable

    顾名思义,Immutable Memtable 就是在内存中只读的 MemTable,由于内存是有限的,通常我们会设置一个阀值,当 MemTable 占用的内存达到阀值后就自动转换为 Immutable Memtable,Immutable Memtable 和 MemTable 的区别就是它是只读的,系统此时会生成新的 MemTable 供写操作继续写入。
    之所以要使用 Immutable Memtable,就是为了避免将 MemTable 中的内容序列化到磁盘中时会阻塞写操作。

    SSTable


    SSTable 就是 MemTable 中的数据在磁盘上的有序存储,其内部数据是根据 key 从小到大排列的。通常为了加快查找的速度,需要在 SSTable 中加入数据索引,可以快读定位到指定的 k-v 数据。
    SSTable 通常采用的分级的结构,例如 LevelDB 中就是如此。MemTable 中的数据达到指定阀值后会在 Level 0 层创建一个新的 SSTable。当某个 Level 下的文件数超过一定值后,就会将这个 Level 下的一个 SSTable 文件和更高一级的 SSTable 文件合并,由于 SSTable 中的 k-v 数据都是有序的,相当于是一个多路归并排序,所以合并操作相当快速,最终生成一个新的 SSTable 文件,将旧的文件删除,这样就完成了一次合并过程。

    2.合并

    LevelDB写入操作很简单,但是读取操作比较复杂,需要在内存以及各个层级文件中按照从新到老依次查找,代价很高。为了加快读取速度,LevelDB内部会执行Compaction操作来对已有的记录进行整理压缩,从而删除一些不再有效的记录,减少数据规模和文件数量。
    LevelDB的Compaction操作分为两种:minor compaction和major compaction。Minor compaction是指当内存中的MemTable大小到了一定值时,将内存数据转储到SSTable文件中。每个层级下有多个SSTable,当某个层级下的SSTable文件数目超过一定设置值后,levelDB会从这个层级中选择SSTable文件,将其和高一层级的SSTable文件合并,这就是major compaction。major compaction相当于执行一次多路归并:按照主键顺序依次迭代出所有SSTable文件中的记录,如果没有保存价值,则直接抛弃;否则,将其写入到新生成的SSTable文件中。

    常用操作的实现

    写入


    在 LSM Tree 中,写入操作是相当快速的,只需要在 WAL 文件中顺序写入当次操作的内容,成功之后将该 k-v 数据写入 MemTable 中即可。尽管做了一次磁盘 IO,但是由于是顺序追加写入操作,效率相对来说很高,并不会导致写入速度的降低。数据写入 MemTable 中其实就是往 SkipList 中插入一条数据,过程也相当简单快速。

    更新

    更新操作其实并不真正存在,和写入一个 k-v 数据没有什么不同,只是在读取的时候,会从 Level0 层的 SSTable 文件开始查找数据,数据在低层的 SSTable 文件中必然比高层的文件中要新,所以总能读取到最新的那条数据。也就是说此时在整个 LSM Tree 中可能会同时存在多个 key 值相同的数据,只有在之后合并 SSTable 文件的时候,才会将旧的值删除。

    删除

    删除一条记录的操作比较特殊,并不立即将数据从文件中删除,而是记录下对这个 key 的删除操作标记,同插入操作相同,插入操作插入的是 k-v 值,而删除操作插入的是 k-del 标记,只有当合并 SSTable 文件时才会真正的删除。

    Compaction

    当数据不断从 Immutable Memtable 序列化到磁盘上的 SSTable 文件中时,SSTable 文件的数量就不断增加,而且其中可能有很多更新和删除操作并不立即对文件进行操作,而只是存储一个操作记录,这就造成了整个 LSM Tree 中可能有大量相同 key 值的数据,占据了磁盘空间。
    为了节省磁盘空间占用,控制 SSTable 文件数量,需要将多个 SSTable 文件进行合并,生成一个新的 SSTable 文件。比如说有 5 个 10 行的 SSTable 文件要合并成 1 个 50 行的 SSTable 文件,但是其中可能有 key 值重复的数据,我们只需要保留其中最新的一条即可,这个时候新生成的 SSTable 可能只有 40 行记录。
    通常在使用过程中我们采用分级合并的方法,其特点如下:
    1. 每一层都包含大量 SSTable 文件,key 值范围不重复,这样查询操作只需要查询这一层的一个文件即可。(第一层比较特殊,key 值可能落在多个文件中,并不适用于此特性)
    2. 当一层的文件达到指定数量后,其中的一个文件会被合并进入上一层的文件中。

    读取


    LSM Tree 的读取效率并不高,当需要读取指定 key 的数据时,先在内存中的 MemTable 和 Immutable MemTable 中查找,如果没有找到,则继续从 Level 0 层开始,找不到就从更高层的 SSTable 文件中查找,如果查找失败,说明整个 LSM Tree 中都不存在这个 key 的数据。如果中间在任何一个地方找到这个 key 的数据,那么按照这个路径找到的数据都是最新的。
    在每一层的 SSTable 文件的 key 值范围是不重复的,所以只需要查找其中一个 SSTable 文件即可确定指定 key 的数据是否存在于这一层中。Level 0 层比较特殊,因为数据是 Immutable MemTable 直接写入此层的,所以 Level 0 层的 SSTable 文件的 key 值范围可能存在重复,查找数据时有可能需要查找多个文件。

    优化读取

    因为这样的读取效率非常差,通常会进行一些优化,例如 LevelDB 中的 Mainfest 文件,这个文件记录了 SSTable 文件的一些关键信息,例如 Level 层数,文件名,最小 key 值,最大 key 值等,这个文件通常不会太大,可以放入内存中,可以帮助快速定位到要查询的 SSTable 文件,避免频繁读取。
    另外一个经常使用的方法是布隆解析器(Bloom filter),布隆解析器是一个使用内存判断文件是否包含一个关键字的有效方法。

    并发控制

    1、数据库锁

    读锁,写锁

    2、写时复制

    读事务不用加锁
    B+树写时复制执行写操作的步骤:
    1. 拷贝:将从叶子到根节点路径上的所有节点拷贝出来。
    2. 修改:对拷贝的节点执行修改。
    3. 提交:原子地切换根节点的指针,使之指向新的根节点。
    写时复制技术涉及引用计数,对每个节点维护一个引用计数,表示被多少节点引用,如果引用计数变为0,说明没有节点引用,可以被垃圾回收。
    缺点
    1. 每次写操作都要拷贝从叶子节点到根节点路径上的所有节点,写操作成本高。
    2. 多个写操作之间是互斥的,同一时刻只允许一个写操作。

    3、多版本并发控制(MVCC)

    读事务不用加锁
    InnoDB存储引擎:
    对每一行维护了两个隐含的列,一列为行被修改的“时间”,一列为行被删除的“时间”,“时间”即为版本号。
    每当一个事务开始时,InnoDB都会给这个事务分配一个递增的版本号(事务号)。
    对于每一行查询语句,InnoDB都会把这个查询语句的版本号同这个查询语句遇到的行的版本号对比,然后结合不同的事务隔离级别,来决定是否返回改行。

    (1)、SELECT

    对于SELECT语句,只有同时满足下面两个条件的行,才能被返回:
    a) 行的修改版本号小于等于该事务号
    b) 行的删除版本号要么没有被定义,要么大于事务的版本号

    (2)、INSERT

    对于新插入的行,行的修改版本号更新为该事务的事务号。

    (3)、DELETE

    对于删除,InnoDB直接把改行的删除版本号设置为当前的事务号,相当于标记为删除,而不是物理删除。

    (4)、UPDATE

    在更新行的时候,InnoDB会把原来的行复制一份,并把当前的事务号作为改行的修改版本号。

    存储快照实现原理

    存储快照有两种实现方式:COW(写时复制Copy-On-Write)、ROW(写重定向Redirect-On-Write),两种实现方法有区别,造成读写性能、应用场景有比较大的区别。

    COW:

    原理见下图(从网上找的,没自己画)。
    1)原卷数据是A~G。此卷Metedata像指针一样指向这些数据。
    2)当做快照时,重新复制一份Metedata,并且也指向这些A~G数据。
    3)当有数据要写入到源卷时(下图写入D'),写入到D的原位置之前,需要把D拷贝出放到一个新位置。然后修改快照的Metedata的其中一个指针指向拷贝出的位置[D](图中是Snapshot data的存储位置)。同时,把D’写入到D原来的位置。

    此方式可以看出,源卷的Metedata的是没有变化的。对原卷是连续的数据,多次快照,多次写之后还是连续的数据,因此读性能或者对单个位置的多次写性能都不会有很大的影响。
    但是,快照的数据是非连续的,如数据ABCEFG还是在源卷的位置,是连续数据。而数据D在存储的其他位置,非连续。 如果多次快照,不同位置的多次读写后,快照的数据可能就比较混乱。造成对快照的读写延时较大。
    应用场景:
    这种实现方式在第一次写入某个存储位置时需要完成一个读操作(读原位置的数据),两个写操作(写原位置与写快照空间),如果写入频繁,那么这种方式将非常 消耗IO时间。因此可推断,如果预计某个卷上的I/O多数以读操作为主,写操作较少的场景,这种方式的快照实现技术是一个较理想的选择,因为快照的完成需要较少 的时间。除此之外,如果一个应用易出现写入热点,即只针对某个有限范围内的数据进行写操作,那么COW的快照实现方式也是较较理想的选择。因为其数据更改都局限在一个范围内,对同一份数据的多次写操作只会出现一次写时复制操作。
    但是这种方式的缺点也是非常明显的。如果写操作过于分散且频繁,那么 COW造成的开销则是不可忽略的,有时甚至是无法接受的。因此在应用时,则需要综合评估应用系统的使用场景,以判断这种方式的快照是否适用。

    ROW:

    原理见下图:
    Vd是源卷的Metedata,分别指向4块数据。做快照时,snap的metadata也指向此4块数据。当有数据写入时,把数据写入另外一个位置,然后修改vd的其中一个metedata到新位置。snap的metedata数据不变化。

    此方式源卷经过长时间写后,所有数据块的位置可能都会重定向到其他位置,导致源卷的数据不连续。在集中式存储情况下,会导致对源卷的读写性能降低。

    两种方式的优缺点,及应用场景:
    COW最大的问题是对写性能有影响。第一次修改原卷,需要复制数据,因此需要多一次读写的数据块迁移过程。这个就比较要命,应用需要等待时间比较长。但原卷数据的布局没有任何改变,因此对读性能没有任何影响。
    ROW在传统存储情况下最大的问题是对读性能影响比较大。ROW写的时候性能基本没有损耗,只是修改指针,实现效率很高。但多次读写后,原卷的数据就分散到各个地方,对于连续读写的性能不如COW。这种方式比较适合Write-Intensive(写密集)类型的存储系统
    但是,在分布式存储的情况下,ROW的连续读写的性能会比COW差吗? 就不一定了。正常情况下,读写性能的瓶颈一般是在磁盘上。分布式存储情况下,业务层看到连续存储,实际上是分布在不同的服务器的不同硬盘中,数据越是分散,系统性能越高。而ROW把原数据打散之后,对性能反而有好处。
    因此,整体情况下ROW基本上是对读写性能影响较小,因此是业界发展方向。

    下图是几个厂家的快照实现方式:

    目前分布式存储比较流行,华为有个FusionStorage数据,说是无限次快照,而且0性能下降,vSAN快照10%~30%的性能下降。从上面的分析来看,就知道两个场景的实现方法了。 

    快照另外一个非常重要的特性是快照一致性组(Consistency Group),这个功能就是支持多个LUN或者叫卷volume同时做快照,保证数据的一致性。
    如果采用阵列的快照来做数据库的备份,必须所有的LUN都是一个时间点的才行,这样数据库恢复的时候才能起来,否则数据库必须回滚到某一个一致的时间点,意味数据的丢失。比较完美的做法就是在主 机安装一个快照的agent,最好是多路径软件具备这个功能,在高端存储要做快照的时候,对主机的快照agent说,别动, 要照相了。主机agent接受到摄影师的命令后,把ORACEL主机缓存的内容flush一下到陈列来,然后hold住,阵列也尽快把cache的内容 flush到硬盘里,ORACLE用到的所有硬盘一块喊”茄子“,摄像师一按快门,一幅完美的快照就产生了。
    一致性组除了保证照相的时候一致性外,还有恢复的时候要一致性恢复。这块的实现的重要性就不如照相的时候重要,可以人工选择同一时间的LUN快照恢复就可以了。最重要的是照相的时候必须要一致,而且这个人工干不了。
    展开全文
  • MySQL-存储引擎

    万次阅读 2020-07-10 13:50:50
    文章目录MySQL-存储引擎1、存储引擎a、InnoDBb、MyISAMc、MySQL内建存储引擎d、第三方存储引擎2、存储引擎的选择3、转换存储引擎 1、存储引擎 a、InnoDB b、MyISAM c、MySQL内建存储引擎 d、第三方存储引擎 2、存储...
  • 一、为什么要确定存储引擎 外键很好使,但是外键的操作需要存储引擎的支持,如果存储引擎不支持外键操作,那么外键时没有用的。 二、什么是存储引擎 存储引擎就是表的数据结构,表的管理方式。不同的表的管理方式...
  • Mysql 常见三种存储引擎 innoDB存储引擎 MyISAM存储引擎 MEMORY存储引擎** innoDB存储引擎特点及优缺点 innoDB存储引擎支持自动增长列(auto_increment) innoDB存储引擎中支持外键(foreign key) 优点: 提供良好的...
  • 修改mysql的默认存储引擎 1、查看mysql存储引擎命令, 在mysql&gt;提示符下搞入show engines; 字段 Support为:Default表示默认存储引擎 2、设置InnoDB为默认引擎: 在配置文件my.cnf中的 [mysqld] 下面加入...
  • MySQL存储引擎

    千次阅读 2020-01-30 15:03:40
    MySQL存储引擎存储引擎MySQL存储引擎 存储引擎   MySQL数据库在实际的工作中分为了语句分析层和存储引擎层,其中语句分析层主要负责与客户端完成连接并且事先分析出SQL语句的内容和功能,存储引擎层则主要负责接收...
  • 面试题:MyISAM存储引擎与InnoDB存储引擎 1. mysql引擎介绍 从MySQL5.1开始,MySQL引入了一个新的概念,插件式存储引擎体系结构。可以做到存储引擎层与SQL层各自更为独立,耦合更小,最重要的是方便了存储引擎的加载...
  • Mysql的存储引擎之:MERGE存储引擎

    千次阅读 2015-09-02 17:24:01
    Merge是基于MyISAM存储引擎的表,所以Merge存储引擎也叫做MGR_MyISAM存储引擎,作用是将一组MyISAM存储引擎的表聚合成一张表。 Merge中要聚合的MyISAM表的列和索引必须有相同的定义及顺序。 建立MERGE存储引擎...
  • 在实际工作中,选择一个合适的存储引擎是一个很复杂的问题。每种存储引擎都有各自的优势,不能笼统的说谁好谁不好。 OK,现在我们将对各个存储引擎的特点进行对比,给出不同情况下选择存储引擎的建议。 首先呢,...
  • Memory存储引擎

    2020-08-03 11:33:02
    Memory存储引擎也称HEAP存储引擎,所有的数据都保存在内存中,如果MySQL服务重启,数据将会丢失,但是表的结构会保存下来 功能特点 支持HASH索引和BTree索引(默认HASH索引) 所有字段都为固定长度,例如varchar(10)=...
  • 从MongodDB3.2.6版本开始,内存存储引擎是64位版本的的一部分,除了一些元数据和一些诊断数据之外,内存存储引擎不维护硬盘上的任何数据,包括配置数据、索引、用户认证。 通过避免数据库的I/O,内存存储引擎可以...
  • 数据库存储引擎

    千次阅读 2019-02-18 11:37:44
    存储引擎(处理表的处理器)  1、基本操作  1、查看所有的存储引擎  show engines;  2、查看已有表的存储引擎  show create table 表名;  ## engine=innodb  3、创建表时指定存储引擎  create table...
  • MyISAM存储引擎

    2020-08-03 10:15:59
    MyISAM引擎作为MYSQL5.5版本之前的默认存储引擎,创建表时如果使用这个存储引擎,成功创建表后将会生成MYD(数据文件)和MYI(索引文件)两个文件 什么是锁 锁主要作用是管理共享资源的并发访问 锁用于实现事务的隔离性...
  • Mysql的存储引擎之:ARCHIVE存储引擎

    千次阅读 2015-09-01 16:26:14
    ARCHIVE存储引擎: 顾名思义:归档(是适用于存放大量数据的存储引擎); 支持select、insert等操作; 不支持delete 、update、索引等操作; 使用zlib无损数据压缩算法,节省空间; 适用于大量历史数据(可...
  • MariaDB存储引擎

    万次阅读 2019-09-20 15:59:29
    是一种插入式的存储引擎概念。这决定了MariaDB数据库中的表可以用不同的方式存储。用户可以根据自己的不同要求,选择不同的存储方式、是否进行事务处理等。    使用SHOW ENGINES语句可以查看MariaDB数据库支持的...
  • MySQL从2007年开始提供了插件式的存储引擎API,从此涌出了一系列为不同目的而设计的存储引擎。其中一些已经合并到MySQL服务器,但大多数还是第三方产品或者开源项目。 1 OLTP类引擎 Percona的XtraDB存储引擎是基于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 66,227
精华内容 26,490
关键字:

存储引擎