高性能MySQL阅读笔记----第一章

第一章 MySQL架构与历史


1.1 MySQL逻辑机构

MySQL存储逻辑结构
第一层,即最上一层,所包含的服务并不是MySQL所独有的技术。它们都是服务于C/S程序或者是这些程序所需要的 :连接处理,身份验证,安全性等等。
第二层值得关注。这是MySQL的核心部分。通常叫做 SQL Layer。在 MySQL据库系统处理底层数据之前的所有工作都是在这一层完成的,包括权限判断, sql解析,行计划优化, query cache 的处理以及所有内置的函数(如日期,时间,数学运算,加密)等等。各个存储引擎提供的功能都集中在这一层,如存储过程,触发器,视 图等。
第三层包括了存储引擎。通常叫做StorEngine Layer ,也就是底层数据存取操作实现部分,由多种存储引擎共同组成。它们负责存储和获取所有存储在MySQL中的数据。就像Linux众多的文件系统 一样。每个存储引擎都有自己的优点和缺陷。服务器是通过存储引擎API来与它们交互的。这个接口隐藏 了各个存储引擎不同的地方。对于查询层尽可能的透明。这个API包含了很多底层的操作。如开始一个事 物,或者取出有特定主键的行。存储引擎不能解析SQL,互相之间也不能通信。仅仅是简单的响应服务器 的请求。
1.1.1连接管理和安全
在服务器内部,每个client连接都有自己的线程。这个连接的查询都在一个单独的线程中执行。这些线程轮流运行在某一个CPU内核(多核CPU)或者CPU中。服务器缓存了线程,因此不需要为每个client连接单独创建和销毁线程 。
当clients(也就是应用程序)连接到了MySQL服务器。服务器需要对它进行认证(Authenticate)。认证是基于用户名,主机,以及密码。对于使用了SSL(安全套接字层)的连接,还使用了X.509证书。clients一连接上,服务器就验证它的权限 (如是否允许客户端可以查询world数据库下的Country表的数据)。
1.1.2优化和执行
MySQL会解析查询,并创建了一个内部数据结构(解析树)。然后对其进行各种优化。这些优化包括了,查询语句的重写,读表的顺序,索引的选择等等。用户可以通过查询语句的关键词传递给优化器以便提示使用哪种优化方式,这样即影响了优化器的优化方式。另外,用户也可以请求服务器给出优化过程的各种说明,以获知服务器的优化策略,为用户提供了参数基准,以便用户可以重写查询,架构和修改相关服务器配置,便于mysql更高效的运行。
优化器并是不关心表使用了哪种存储引擎,但是存储引擎对服务器优化查询的方式是有影响的。优化器需要知道存储引擎的一些特性:具体操作的性能和开销方面的信息,以及表内数据的统计信息。例如,存储引擎支持哪些索引类型,这对于查询是非常有用的。
在解析查询之前,要查询缓存,这个缓存只能保存查询信息以及结果数据。如果请求一个查询在缓存 中存在,就不需要解析,优化和执行查询了。直接返回缓存中所存放的这个查询的结果。

1.2 并发控制

1.2.1读写锁
1.共享锁(shared lock,读锁):共享的,相互不阻塞的。
2.排他锁(exclusive lock,写锁):排他的,一个写锁会阻塞其他的写锁和读锁。
1.2.2锁粒度
表锁:MySQL中最基本的锁策略,并且是开销最小的策略。
行级锁:可以最大程度地支持并发处理,但是会带来极大的开销。

1.3事务

ACID特性
  • 原子性(atomicity)
    一个事务必须被视为一个不可分割的最小工作单元,整个事务中所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分操作
  • 一致性(consistency)
    数据库总是从一个一致性的状态转换到另外一个一致性的状态
  • 隔离性(isolation)
    一个事务所做的修改在最终提交以前,对其他事务是不可见的
  • 持久性(durability)
    一旦事务提交,则其所做的修改就会永久保存到数据库中
1.3.1隔离级别
在SQL标准中定义四种隔离级别,每一种隔离级别都规定了一个事务中所做的修改,哪些是事务内部和事务之间可见的,哪些是不可见的。较低级别的隔离通常可以执行更高的并发,系统的开销也更低。
  • READ UNCOMMITTED(未提交读)
    事务中的修改,即使没有提交,对其他事务也都是可见的,事务可以读取未提交的数据,也被称为脏读(Dirty Read),这个级别会导致很多问题,实际中很少使用
  • READ COMMITTED(提交读)
    大多数数据库系统的默认隔离级别,一个事务开始时,只能“看见”已经提交的事务所做的修改,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的,也叫不可重复读(nonrepeatable read),因为两次执行同样的查询,得到的结果是不同的
  • REPEATABLE READ(可重复读)
    这个级别可以解决脏读问题,保证了在同一个事务中多次读取同样记录的结果是一致的。但是有可能无法解决幻读的问题。所谓的幻读(Phantom Read)指的是当某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录,当之前的事务再次读取该范围的记录时,会产生幻行(Phantom Row)。
    通过InnoDB和XtraDB存储引擎,是MySQL的默认事务隔离级别
  • SERIALIZABLE(可串行化)
    最高级别,通过强制事务串行执行,避免了幻读问题,会在读取的每一行数据上都加锁,可能导致大量的超时和锁争用的问题,适用于非常需要确保数据的一致性而且可以接受没有并发的情况
1.3.2死锁
死锁:指两个或多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象。
需要注意的是,锁的行为和顺序是和存储引擎相关联的。以同样的书序执行的语句,在某些引擎中会产生死锁,但是在某些引擎中是不会产生死锁的。
1.3.3事务日志
储引擎在修改表的数据时只需要修改其内存拷贝,再把该修改行为记录到持久在硬盘上的事务日志中,而不用每次都将修改的数据本身持久到磁盘。事务日志持久以后,内存中被修改的数据在后台可以慢慢地刷回到磁盘,称为预写式日志(Write-Ahead Logging)
1.3.4MySQL中的事务
MySQL提供两种事务型存储引擎:InnoDB和NDB Cluster。
自动提交模式:MySQL的默认模式,将每一条查询都看作一个事务执行提交操作。
由于MySQL服务器层面不进行事务的管理,而是交过下层的存储引擎实现,所以在同一个事务中,使用多种存储引擎是不可靠的。

1.4多版本并发控制

  • 多版本并发控制(MVCC)是行级锁的一个变种,但是它在很多情况下避免了加锁操作,因此开销更低。虽然实现机制有所不同,但大都实现了非阻塞的读操作,写操作也只锁定必要的行
  • MVCC的实现,是通过保存数据在某个时间点的快照来实现的,有乐观和悲观两种,只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作

特别说明:InnoDB实现MVCC的方法

InnoDB实现MVCC的方法是,它存储了每一行的两个(1)额外的隐藏字段,这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时候,每行存储版本号,而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始,每个事物都会保存记录的系统版本号。依照事物的 版本来检查每行的版本号。在事物隔离级别为可重复读的情况下,来看看怎样应用它。
  • SELECT
    Innodb检查没行数据,确保他们符合两个标准:
    1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本),这确保当前事务读取的行都是事务之前已经存在的,或者是由当前事务创建或修改的行
    2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当前事务开始之前,行没有被删除(2)
    符合了以上两点则返回查询结果。
  • INSERT
    InnoDB为每个新增行记录当前系统版本号作为创建ID。
  • DELETE
    InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。
  • UPDATE
    InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。

1.5MySQL的存储引擎

  • MyISAM
    它不支持事务,也不支持外键,尤其是访问速度快,对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
    每个MyISAM在磁盘上存储成3个文件,其中文件名和表名都相同,但是扩展名分别为:
    .frm(存储表定义)
    MYD(MYData,存储数据)
    MYI(MYIndex,存储索引)
    数据文件和索引文件可以放置在不同的目录,平均分配IO,获取更快的速度。要指定数据文件和索引文件的路径,需要在创建表的时候通过DATA DIRECTORY和INDEX DIRECTORY语句指定,文件路径需要使用绝对路径。
    每个MyISAM表都有一个标志,服务器或myisamchk程序在检查MyISAM数据表时会对这个标志进行设置。MyISAM表还有一个标志用来表明该数据表在上次使用后是不是被正常的关闭了。如果服务器以为当机或崩溃,这个标志可以用来判断数据表是否需要检查和修复。如果想让这种检查自动进行,可以在启动服务器时使用--myisam-recover现象。这会让服务器在每次打开一个MyISAM数据表是自动检查数据表的标志并进行必要的修复处理。MyISAM类型的表可能会损坏,可以使用CHECK TABLE语句来检查MyISAM表的健康,并用REPAIR TABLE语句修复一个损坏到MyISAM表。
      
    MyISAM的表还支持3种不同的存储格式:静态(固定长度)表、动态表、压缩表
      其中静态表是默认的存储格式。静态表中的字段都是非变长字段,这样每个记录都是固定长度的,这种存储方式的优点是存储非常迅速,容易缓存,出现故障容易恢复;缺点是占用的空间通常比动态表多。静态表在数据存储时会根据列定义的宽度定义补足空格,但是在访问的时候并不会得到这些空格,这些空格在返回给应用之前已经去掉。同时需要注意:在某些情况下可能需要返回字段后的空格,而使用这种格式时后面到空格会被自动处理掉。
      动态表包含变长字段,记录不是固定长度的,这样存储的优点是占用空间较少,但是频繁到更新删除记录会产生碎片,需要定期执行OPTIMIZE TABLE语句或myisamchk -r命令来改善性能,并且出现故障的时候恢复相对比较困难。
      压缩表由myisamchk工具创建,占据非常小的空间,因为每条记录都是被单独压缩的,所以只有非常小的访问开支。

  • InnoDB
    InnoDB是一个健壮的事务型存储引擎,这种存储引擎已经被很多互联网公司使用,为用户操作非常大的数据存储提供了一个强大的解决方案。我的电脑上安装的MySQL 5.6.13版,InnoDB就是作为默认的存储引擎。InnoDB还引入了行级锁定和外键约束,在以下场合下,使用InnoDB是最理想的选择:
    1.更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。
    2.事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。
    3.自动灾难恢复。与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。
    4.外键约束。MySQL支持外键的存储引擎只有InnoDB。
    5.支持自动增加列AUTO_INCREMENT属性。
    一般来说,如果需要事务支持,并且有较高的并发读取频率,InnoDB是不错的选择。

  • MEMORY
    使用MySQL Memory存储引擎的出发点是速度。为得到最快的响应时间,采用的逻辑存储介质是系统内存。虽然在内存中存储表数据确实会提供很高的性能,但当mysqld守护进程崩溃时,所有的Memory数据都会丢失。获得速度的同时也带来了一些缺陷。它要求存储在Memory数据表里的数据使用的是长度不变的格式,这意味着不能使用BLOB和TEXT这样的长度可变的数据类型,VARCHAR是一种长度可变的类型,但因为它在MySQL内部当做长度固定不变的CHAR类型,所以可以使用。
    一般在以下几种情况下使用Memory存储引擎:
    1.目标数据较小,而且被非常频繁地访问。在内存中存放数据,所以会造成内存的使用,可以通过参数max_heap_table_size控制Memory表的大小,设置此参数,就可以限制Memory表的最大大小。
    2.如果数据是临时的,而且要求必须立即可用,那么就可以存放在内存表中。
    3.存储在Memory表中的数据如果突然丢失,不会对应用服务产生实质的负面影响。

Memory同时支持散列索引和B树索引。
B树索引的优于散列索引的是,可以使用部分查询和通配查询,也可以使用<、>和>=等操作符方便数据挖掘。散列索引进行“相等比较”非常快,但是对“范围比较”的速度就慢多了,因此散列索引值适合使用在=和<>的操作符中,不适合在<或>操作符中,也同样不适合用在order by子句中。

  • MERGE
    MERGE存储引擎是一组MyISAM表的组合,这些MyISAM表结构必须完全相同,尽管其使用不如其它引擎突出,但是在某些情况下非常有用。说白了,Merge表就是几个相同MyISAM表的聚合器;Merge表中并没有数据,对Merge类型的表可以进行查询、更新、删除操作,这些操作实际上是对内部的MyISAM表进行操作。Merge存储引擎的使用场景。
    对于服务器日志这种信息,一般常用的存储策略是将数据分成很多表,每个名称与特定的时间端相关。例如:可以用12个相同的表来存储服务器日志数据,每个表用对应各个月份的名字来命名。当有必要基于所有12个日志表的数据来生成报表,这意味着需要编写并更新多表查询,以反映这些表中的信息。与其编写这些可能出现错误的查询,不如将这些表合并起来使用一条查询,之后再删除Merge表,而不影响原来的数据,删除Merge表只是删除Merge表的定义,对内部的表没有任何影响。

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

存储引擎的一些问题

1.如何查看服务器有哪些存储引擎可以使用?
为确定你的MySQL服务器可以用哪些存储引擎,执行如下命令:show engines就能搞定了。
2.如何选择合适的存储引擎?
(1)选择标准可以分为:
(2)是否需要支持事务;
(3)是否需要使用热备;
(4)崩溃恢复:能否接受崩溃;
(5)是否需要外键支持;
然后按照标准,选择对应的存储引擎即可。

你可能感兴趣的:(高性能MySQL阅读笔记----第一章)