存储引擎

MySQL引擎的和区别

狂风中的少年 提交于 2020-03-27 11:52:03
转载自 https://m.nowcoder.com/tutorial/93/8ac75a692a3b4b0a868796b9f008bc2c MySQL引擎 MySQL中的数据用各种不同的技术存储在文件(或内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧和锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术,你能够获得额外的速度或功能,从而改善你的应用的总体功能。 数据库引擎是用于存储、处理和保护数据的核心服务。利用数据库引擎可控制访问权限并快速处理事务,从而满足企业内大多数需要处理大量数据的应用程序的要求。 MySQL存储引擎主要有:MyISAM、InnoDB、Memory、Blackhole、CSV、Performance_Schema、Archieve、Federated、Mrg_Myiasm. 但是最常用的是InnoDB和MyISAM。 InnoDB InnoDB是一个事务型的存储引擎,有行级锁定和外键约束。 InnoDB引擎提供了对数据库ACID事务的支持,并且实现了SQL的四种隔离级别。 该引擎还提供了行级锁定和外键约束,它的设计目标是处理大容量数据库系统,它本身其实就是基于MySQL后台的完整数据库系统,MySQL运行时InnoDB会在内存中建立缓冲池,用于缓冲数据和索引。 但是该引擎不支持FULLTEXT类型的索引 而且它没有保存表的行数

数据价值挖掘利器!阿里云实时数仓AnalyticDB PG版新一代计算引擎Odyssey技术解析

二次信任 提交于 2020-03-23 16:39:54
3 月,跳不动了?>>> 目的 随着数字经济时代的到来,越来越多的应用依赖数据分析来挖掘数据的价值。作为大数据存储、在线分析的重要基础系统,分析型数据库(OLAP)为数据价值的在线化提供重要的技术平台。 阿里巴巴OLAP团队经过调研发现,现有的OLAP数据库执行引擎往往是在已有的OLTP执行引擎的基础之上,进行二次开发而来,存在性能损耗大、历史包袱重、未充分利用最新优化技术、未充分发挥新硬件优势等问题。 随着数据量的快速增长和数据分析需求的日趋强劲,OLAP系统所需要承担的计算量也呈指数级增长,现有系统的性能难以满足未来的在线数据分析的需求。经过分析,阿里巴巴OLAP团队认为,真正面向全面上云时代、面向数字经济时代的OLAP执行引擎,应当具备如下技术特点: • 支持多种硬件平台 。满足企业上云需求,支持多种硬件平台。除了支持传统X86平台,也应当兼容ARM平台,同时支持利用GPU、FPGA等新兴硬件进行加速。 • 极致性价比 。充分利用硬件性能,精选最佳算法和算子实现,提升硬件执行效率。对于密集、复杂的计算,使用特殊算法特殊硬件来提升效率。 • SQL 兼容性高 。高度兼容现有的SQL标准、优化器标准、存储标准,减少用户的迁移难度和学习难度。用户无需改写SQL,无需重新学习优化技术,无需迁移数据,仅需要进行小版本软件升级,即可享受到最新的性能优化技术。 为了解决如上需求

MySql存储引擎介绍

半世苍凉 提交于 2020-03-23 13:01:28
MySQL5.5以后默认使用 InnoDB 存储引擎,其中InnoDB和BDB提供事务安全表,其它存储引擎都是非事务安全表。 若要修改默认引擎,可以修改配置文件中的default-storage-engine。可以通过:show variables like 'default_storage_engine';查看当前数据库到默认引擎。命令: show engines 和 show variables like 'have%' 可以列出当前数据库所支持到引擎。其中Value显示为disabled的记录表示数据库支持此引擎,而在数据库启动时被禁用。在MySQL5.1以后,INFORMATION_SCHEMA数据库中存在一个ENGINES的表,它提供的信息与show engines;语句完全一样,可以使用下面语句来查询哪些存储引擎支持事物处理:select engine from information_chema.engines where transactions = 'yes'; 可以通过engine关键字在创建或修改数据库时指定所使用到引擎。 主要存储引擎:MyISAM、InnoDB、MEMORY和MERGE介绍: 在创建表到时候通过 engine=... 或 type=... 来指定所要使用到引擎。 show table status from DBname 来查看指定表到引擎

Mysql 数据库几种引擎的区别比较

China☆狼群 提交于 2020-03-23 12:46:42
数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还可以 获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。MySql的核心就是存储引擎。 存储引擎查看 MySQL给开发者提供了查询存储引擎的功能,我这里使用的是MySQL5.1,可以使用: SHOW ENGINES 命令来查看MySQL使用的引擎,命令的输出为(我用的Navicat Premium): 看到MySQL给用户提供了这么多存储引擎,包括处理事务安全表的引擎和出来了非事物安全表的引擎。 如果要想查看数据库默认使用哪个引擎,可以通过使用命令: SHOW VARIABLES LIKE 'storage_engine'; 来查看,查询结果为: 在MySQL中,不需要在整个服务器中使用同一种存储引擎,针对具体的要求,可以对每一个表使用不同的存储引擎。Support列的值表示某种引擎是否能使用:YES表示可以使用、NO表示不能使用、DEFAULT表示该引擎为当前默认的存储引擎 。下面来看一下其中几种常用的引擎。 ========================以上是转载的http://blog.csdn.net/zhangyuan19880606/article/details

理解MySQL——架构与概念

我的梦境 提交于 2020-03-23 12:10:40
写在前面:最早接触的MySQL是在三年前,那时候MySQL还是4.x版本,很多功能都不支持,比如,存储过程,视图,触发器,更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始,MySQL渐渐步入企业级数据库的行列了;复制、集群、分区、分布式事务,这些企业级的特性,使得现在的MySQL,完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器,尽管节约成本是一个因素,但是没有强大功能作后盾,则是不可想象的)。虽然,MySQL还有很多不足,比如,复制、分区的支持都十分有限、查询优化仍需要改进,但是MySQL已经是一个足够好的DBMS了,更何况它是opensource的。这段时间没有事,出于好奇,略微的研究了一下MySQL,积累了一些资料,欲总结出来。这些资料打算分为两部分,上部主要讨论MySQL的优化,其中主要参考了《MySQL Manual》和《High Performance MySQL》,如果有时间,以后在下部分析一下MySQL的源码。如果你是MySQL高手,希望你不吝赐教;如果你是新手,希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的,所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心,包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

第15 章 : 深入解析 Linux 容器

家住魔仙堡 提交于 2020-03-23 04:47:29
深入解析 Linux 容器 今天的内容主要分成以下三个部分 资源隔离和限制; 容器镜像的构成; 容器引擎的构成; 前两个部分就是资源隔离和限制还有容器镜像的构成,第三部分会以一个业界比较成熟的容器引擎为例去讲解一下容器引擎的构成。 容器 容器是一种轻量级的虚拟化技术,因为它跟虚拟机比起来,它少了一层 hypervisor 层。先看一下下面这张图,这张图简单描述了一个容器的启动过程。 最下面是一个磁盘,容器的镜像是存储在磁盘上面的。上层是一个容器引擎,容器引擎可以是 docker,也可以是其它的容器引擎。引擎向下发一个请求,比如说创建容器,然后这时候它就把磁盘上面的容器镜像,运行成在宿主机上的一个进程。 对于容器来说,最重要的是怎么保证这个进程所用到的资源是被隔离和被限制住的,在 Linux 内核上面是由 cgroup 和 namespace 这两个技术来保证的。接下来以 docker 为例,来详细介绍一下资源隔离和容器镜像这两部分内容。 一、资源隔离和限制 namespace namespace 是用来做资源隔离的,在 Linux 内核上有七种 namespace,docker 中用到了前六种。第七种 cgroup namespace 在 docker 本身并没有用到,但是在 runC 实现中实现了 cgroup namespace。 我们先从头看一下: 第一个是 mount

理解MySQL——架构与概念

末鹿安然 提交于 2020-03-20 18:28:59
写在前面:最早接触的MySQL是在三年前,那时候MySQL还是4.x版本,很多功能都不支持,比如,存储过程,视图,触发器,更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始,MySQL渐渐步入企业级数据库的行列了;复制、集群、分区、分布式事务,这些企业级的特性,使得现在的MySQL,完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器,尽管节约成本是一个因素,但是没有强大功能作后盾,则是不可想象的)。虽然,MySQL还有很多不足,比如,复制、分区的支持都十分有限、查询优化仍需要改进,但是MySQL已经是一个足够好的DBMS了,更何况它是opensource的。这段时间没有事,出于好奇,略微的研究了一下MySQL,积累了一些资料,欲总结出来。这些资料打算分为两部分,上部主要讨论MySQL的优化,其中主要参考了《MySQL Manual》和《High Performance MySQL》,如果有时间,以后在下部分析一下MySQL的源码。如果你是MySQL高手,希望你不吝赐教;如果你是新手,希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的,所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心,包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

Python数据库操作 Mysql数据库表引擎与字符集#学习猿地

被刻印的时光 ゝ 提交于 2020-03-20 12:22:47
# Mysql数据库表引擎与字符集 ![](./imgs/752951346A5F4E7EBDE362FA97107707.png) ### 1.服务器处理客户端请求 其实不论客户端进程和服务器进程是采用哪种方式进行通信,最后实现的效果都是:**客户端进程向服务器进程发送一段文本(MySQL语句),服务器进程处理后再向客户端进程发送一段文本(处理结果)。**那服务器进程对客户端进程发送的请求做了什么处理,才能产生最后的处理结果呢?客户端可以向服务器发送增删改查各类请求,我们这里以比较复杂的查询请求为例来画个图展示一下大致的过程: ![image](./imgs/167f4c7b99f87e1c.png) > 虽然查询缓存有时可以提升系统性能,但也不得不因维护这块缓存而造成一些开销,比如每次都要去查询缓存中检索,查询请求处理完需要更新查询缓存,维护该查询缓存对应的内存区域。从MySQL 5.7.20开始,不推荐使用查询缓存,并在MySQL 8.0中删除。 ### 2.存储引擎 `MySQL`服务器把数据的存储和提取操作都封装到了一个叫`存储引擎`的模块里。我们知道`表`是由一行一行的记录组成的,但这只是一个逻辑上的概念,物理上如何表示记录,怎么从表中读取数据,怎么把数据写入具体的物理存储器上,这都是`存储引擎`负责的事情。为了实现不同的功能,`MySQL`提供了各式各样的`存储引擎`

MongoDB-New flexible storage architecture

感情迁移 提交于 2020-03-20 06:18:53
MongoDB从2.8开始,有了新的更灵活的存储架构,引入了存储引擎API,目前已经支持两种存储引擎MMAPv1和WiredTiger。 MMAPv1 - MongoDB2.8版本的默认存储引擎,其基于内存映射技术的存储引擎,支持集合级锁(Collection Level Locking)。 WiredTiger - MongoDB3.0版本的默认存储引擎 ,(3.0正式版发布后,MMAPv1为默认存储引擎2015.3.5)BerkerlyDB 架构师开发的存储引擎,主要特点为高性能写入、支持压缩(Snappy和Zlib,Snappy默认)和文档级锁(Document Level Locking)。 备注: 存储引擎 - 存储引擎是数据库管理系统的一个重要组成部分,它的主要职责是把数据存储到磁盘和把数据从磁盘中检索出来。不同的存储引擎对不同的应用需求有特殊的优化。 存储引擎API - 存储引擎API提供统一的接口,可以让特定用户,根据特定的性能、可用性、高效性、容量及扩展性等具体需求开发适合于这些场景的存储引擎。 Snappy - Snappy 是一个 C++ 的用来压缩和解压缩的开发包,其目标不是最大限度压缩,而且不兼容其他压缩格式。Snappy 旨在提供高速压缩速度和合理的压缩率。Snappy 比 zlib 更快,但文件相对要大 20% 到 100%。在 64位模式的 Core

MySQL中Cardinality值的介绍

倖福魔咒の 提交于 2020-03-19 00:35:34
1) 什么是Cardinality 不是所有的查询条件出现的列都需要添加索引。对于什么时候添加B+树索引。一般的经验是,在访问表中很少一部分时使用B+树索引才有意义。对于性别字段、地区字段、类型字段,他们可取值范围很小,称为低选择性。如 SELECT * FROM student WHERE sex='M' 按性别进行查询时,可取值一般只有M、F。因此SQL语句得到的结果可能是该表50%的数据(加入男女比例1:1)这时添加B+树索引是完全没有必要的。相反,如果某个字段的取值范围很广,几乎没有重复,属于高选择性。则此时使用B+树的索引是最合适的。例如对于姓名字段,基本上在一个应用中不允许重名的出现 怎样查看索引是否有高选择性?通过SHOW INDEX结果中的列Cardinality来观察。非常关键,表示所以中不重复记录的预估值,需要注意的是Cardinality是一个预估值,而不是一个准确值基本上用户也不可能得到一个准确的值,在实际应用中,Cardinality/n_row_in_table应尽可能的接近1,如果非常小,那用户需要考虑是否还有必要创建这个索引。故在访问高选择性属性的字段并从表中取出很少一部分数据时,对于字段添加B+树索引是非常有必要的。如 SELECT * FROM member WHERE usernick='David'; 表member大约有500W行数据