MYSQL存储引擎解释

存储引擎解释

　　首先确定一点，存储引擎的概念是MySQL里面才有的，不是所有的关系型数据库都有存储引擎这个概念，

​ MySQL支持多种存储引擎，每种引擎有着一些自己独特的功能，用户在使用的时候，可以根据自己的业务场景来使用不同的存储引擎，其中MySQL最常用的存储引擎为：MyISAM和InnoDB。
在详细介绍这些存储引擎之前，我们先来看看MySQL的整个工作流程，看一下存储引擎在哪里，MySQL都做了哪些事情。
​ 　　　　

MySQL存储引擎分类

　　首先看一下咱们的默认存储引擎：

　　

不同的引擎代表着不同的存取机制，那么有哪些引擎呢，连接进入mysql之后，查看MySQL支持的所有存储引擎：

  1. show engines；#查看MySQL所有的引擎，

　　　　

  1. show variables like "storage_engine%";查看当前正在使用的引擎

　　　　

　　　　注意：在存储大文件的时候，可以存到数据库，但是尽量别直接存到数据库里面，会影响数据库的效率，我们就存文件的路径、地址，用户想要这个大文件，我们可以到对应的路径下取读取这个文件给用户。

几种常用引擎介绍

MyISAM引擎

  1. 不支持事务 事务是指逻辑上的一组操作，组成这组操作的各个单元，要么全成功要么全失败。
  2. 表级锁定 数据更新时锁定整个表：其锁定机制是表级锁定，也就是对表中的一个数据进行操作都会将这个表锁定，其他人不能操作这个表，这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能。
  3. 读写互相阻塞 不仅会在写入的时候阻塞读取，MyISAM还会再读取的时候阻塞写入，但读本身并不会阻塞另外的读。
  4. 只会缓存索引 MyISAM可以通过key_buffer_size的值来提高缓存索引，以大大提高访问性能减少磁盘IO，但是这个缓存区只会缓存索引，而不会缓存数据。
  5. 读取速度较快 占用资源相对较少
  6. 不支持外键约束，但只是全文索引
  7. MyISAM引擎是MySQL5.5版本之前的默认引擎，是对最初的ISAM引擎优化的产物。
MyISAM引擎适用的生产业务场景
  1. 不需要事务支持的业务(例如转账就不行，充值也不行)
  2. 一般为读数据比较多的应用，读写都频繁场景不适合，读多或者写多的都适合。
  3. 读写并发访问都相对较低的业务(纯读纯写高并发也可以)(锁定机制问题)
  4. 数据修改相对较少的业务(阻塞问题)
  5. 以读为主的业务，例如：blog,图片信息数据库，用户数据库，商品库等业务
  6. 对数据一致性要求不是很高的业务。
  7. 中小型的网站部分业务会用。
  8. 小结：单一对数据库的操作都可以示用MyISAM，所谓单一就是尽量纯读，或纯写(insert,update,delete)等。

MyISAM引擎调优精要

  1. 设置合适的索引(缓存机制)(where、join后面的列建立索引，重复值比较少的建索引等)
  2. 调整读写优先级，根据实际需求确保重要操作更优先执行，读写的时候可以通过参数设置优先级。
  3. 启用延迟插入改善大批量写入性能(降低写入频率，尽可能多条数据一次性写入)。
  4. 尽量顺序操作让insert数据都写入到尾部，较少阻塞。
  5. 分解大的操作，降低单个操作的阻塞时间，就像操作系统控制cpu分片一样。
  6. 降低并发数(减少对MySQL访问)，某些高并发场景通过应用进行排队队列机制Q队列。
  7. 对于相对静态(更改不频繁)的数据库数据，充分利用Query Cache(可以通过配置文件配置)或memcached缓存服务可以极大的提高访问频率。
  8. MyISAM的Count只有在全表扫描的时候特别高效，带有其他条件的count都需要进行实际的数据访问。
  9. 可以把主从同步的主库使用innodb，从库使用MyISAM引擎。主库写，从库读可以(不推荐，有些麻烦的地方，市场上有人这么用)。

不支持事务、表锁设计、支持全文索引,主要面向一些 OLAP 数 据库应用,在 MySQL 5.5.8 版本之前是默认的存储引擎(除 Windows 版本外)。数据库系统 与文件系统一个很大的不同在于对事务的支持,MyISAM 存储引擎是不支持事务的。究其根 本,这也并不难理解。用户在所有的应用中是否都需要事务呢?在数据仓库中,如果没有 ETL 这些操作,只是简单地通过报表查询还需要事务的支持吗?此外,MyISAM 存储引擎的 另一个与众不同的地方是,它的缓冲池只缓存(cache)索引文件,而不缓存数据文件,这与 大多数的数据库都不相同。

InnoDB引擎

InnoDB引擎适用的生产业务场景

  1. 需要事务支持(具有较好的事务特性，例银行业务)
  2. 行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成。
  3. 数据更新较为频繁的场景，如：BBS(论坛)、SNS(社交平台)、微博等
  4. 数据一致性要求较高的业务，例如：充值转账，银行卡转账。
  5. 硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘IO，可以通过一些参数来设置
  6. 相比MyISAM引擎，Innodb引擎更消耗资源，速度没有MyISAM引擎快

InnoDB引擎调优精要

  1. 主键尽可能小，避免给Secondery index带来过大的空间负担。
  2. 避免全表扫描，因为会使用表锁。
  3. 尽可能缓存所有的索引和数据，提高响应速度，较少磁盘IO消耗。
  4. 在大批量小插入的时候，尽量自己控制事务而不要使用autocommit自动提交，有开关可以控制提交方式。
  5. 合理设置innodb_flush_log_at_trx_commit参数值，不要过度追求安全性。 如果innodb_flush_log_at_trx_commit的值为0，log buffer每秒就会被刷写日志文件到磁盘，提交事务的时候不做任何操作。
  6. 避免主键更新，因为这会带来大量的数据移动。

其他引擎的介绍

  1. NDB 存储引擎
  2. Memory 存储引擎
  3. Infobright 存储引擎
  4. NTSE 存储引擎BLACKHOLE

事务

事务就是指逻辑上的一组SQL语句操作，组成这组操作的各个SQL语句，执行时要么全成功要么全失败。

事务的四大特性

原子性(Atomicity)

  • 事务是一个不可分割的单位，事务中的所有SQL等操作要么都发生，要么都不发生。

一致性(Consistency)

  • 事务发生前和发生后，数据的完整性必须保持一致。

隔离性(Isolation)

  • 当并发访问数据库时，一个正在执行的事务在执行完毕前，对于其他的会话是不可见的，多个并发事务之间的数据是相互隔离的。也就是其他人的操作在这个事务的执行过程中是看不到这个事务的执行结果的，也就是他们拿到的是这个事务执行之前的内容，等这个事务执行完才能拿到新的数据。

持久性(Durability)

  • 一个事务一旦被提交，它对数据库中的数据改变就是永久性的。如果出了错误，事务也不允撤销，只能通过'补偿性事务'。

事务的开启

  • 开启:begin
  • 提交:'commit'

OLTP与OLAP的介绍

数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLTP与OLAP之间的比较：

img

OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
（1）CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上，逻辑读总量等于单个语句的逻辑读乘以执行次数，如果单个语句执行速度虽然很快，但是执行次数非常多，那么，也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读，或者是减少它们的执行次数。另外，一些计算型的函数，如自定义函数、decode等的频繁使用，也会消耗大量的CPU时间，造成系统的负载升高，正确的设计方法或者是优化方法，需要尽量避免计算过程，如保存计算结果到统计表就是一个好的方法。
（2）磁盘子系统在OLTP环境中，它的承载能力一般取决于它的IOPS处理能力. 因为在OLTP环境中，磁盘物理读一般都是db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。
OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。
OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统。 对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL重用，减少物理I/O 和重复的SQL 解析，从而极大的改善数据库的性能。
这里影响性能除了绑定变量，还有可能是热快（hot block）。 当一个块被多个用户同时读取时，Oracle 为了维护数据的一致性，需要使用Latch来串行化用户的操作。当一个用户获得了latch后，其他用户就只能等待，获取这个数据块的用户越多，等待就越明显。 这就是热快的问题。 这种热快可能是数据块，也可能是回滚端块。 对于数据块来讲，通常是数据库的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
在OLAP系统中，常使用分区技术、并行技术。
分区技术在OLAP系统中的重要性主要体现在数据库管理上，比如数据库加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间实现，删除数据可以通过分区进行删除，至于分区在性能上的影响，它可以使得一些大表的扫描变得很快（只扫描单个分区）。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。总之，分区主要的功能是管理上的方便性，它并不能绝对保证查询性能的提高，有时候分区会带来性能上的提高，有时候会降低。
并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
绑定变量真正的用途是在OLTP系统中，这个系统通常有这样的特点，用户并发数很大，用户的请求十分密集，并且这些请求的SQL 大多数是可以重复使用的。
对于OLAP系统来说，绝大多数时候数据库上运行着的是报表作业，执行基本上是聚合类的SQL 操作，比如group by，这时候，把优化器模式设置为all_rows是恰当的。 而对于一些分页操作比较多的网站类数据库，设置为first_rows会更好一些。 但有时候对于OLAP 系统，我们又有分页的情况下，我们可以考虑在每条SQL 中用hint。 如：
Select a.* from table a;
分开设计与优化
在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。
如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
对于OLAP系统，在内存上可优化的余地很小，增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法，当然这也意味着系统成本的增加。
比如我们要对几亿条或者几十亿条数据进行聚合处理，这种海量的数据，全部放在内存中操作是很难的，同时也没有必要，因为这些数据快很少重用，缓存起来也没有实际意义，而且还会造成物理I/O相当大。 所以这种系统的瓶颈往往是磁盘I/O上面的。
对于OLAP系统，SQL 的优化非常重要，因为它的数据量很大，做全表扫描和索引对性能上来说差异是非常大的。
其他
Oracle 10g以前的版本建库过程中可供选择的模板有：
Data Warehouse （数据仓库）
General Purpose （通用目的、一般用途）
New Database
Transaction Processing （事务处理）
Oracle 11g的版本建库过程中可供选择的模板有：
一般用途或事务处理
定制数据库

​ 数据仓库

个人对这些模板的理解为：

联机分析处理（OLAP,On-line Analytical Processing），数据量大，DML少。使用数据仓库模板
联机事务处理（OLTP,On-line Transaction Processing），数据量少，DML频繁，并行事务处理多，但是一般都很短。使用一般用途或事务处理模板。

决策支持系统（DDS，Decision support system)，典型的操作是全表扫描，长查询，长事务，但是一般事务的个数很少，往往是一个事务独占系统。

存储引擎的使用

　　1、创建表时指定引擎

create table innodb_t2(id int)engine=innodb;

　　2、在配置文件中指定默认的存储引擎

linux:vim /etc/my.cnf   windows:my.ini文件
[mysqld]
default-storage-engine=INNODB  #配置默认引擎，现在用的mysql默认基本都是InnoDB，所以其实都可以不用配置了
innodb_file_per_table=1  #表示独立表空间存储，可以不写

　　3、不同引擎在创建表的时候生成文件的不同

　　　　创建四个表，分别使用innodb，myisam，memory，blackhole存储引擎，进行插入数据测试

#下面是使用四个不同的引擎来创建的表create table t1(id int)engine=innodb;
create table t2(id int)engine=myisam;
create table t3(id int)engine=memory;
create table t4(id int)engine=blackhole;

 

　　　　通过四种引擎来创建的表，我们对照着其生成的文件来看一下区别，看下图：

关于上面的文件作用介绍：

  1. db.opt文件：用来记录该库的默认字符集编码和字符集排序规则用的。也就是说如果你创建数据库指定默认字符集和排序规则，那么后续创建的表如果没有指定字符集和排序规则，那么该新建的表将采用db.opt文件中指定的属性。
  2. 后缀名为.frm的文件：这个文件主要是用来描述数据表结构(id,name字段等)和字段长度等信息
  3. 后缀名为.ibd的文件：这个文件主要储存的是采用独立表储存模式时储存数据库的数据信息和索引信息；
  4. 后缀名为.MYD（MYData）的文件：从名字可以看出，这个是存储数据库数据信息的文件，主要是存储采用独立表储存模式时存储的数据信息；
  5. 后缀名为.MYI的文件：这个文件主要储存的是数据库的索引信息；
  6. ibdata1文件:主要作用也是储存数据信息和索引信息，这个文件在mysql安装目录的data文件夹下。

在Oracle 和SQL Server等所有数据存储管理机制都是一样的。而MySql数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。

Oracle中不存在引擎的概念，数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

转载自 : https://www.cnblogs.com/zhaohaiyu/p/11430278.html

 

posted @ 2020-10-23 15:21  小学生很小  阅读(412)  评论(0)  编辑  收藏  举报