《高性能MySQL》-MySQL架构

1、Mysql的逻辑架构
    a.大体将Mysql分为3层：
        1.mysql客户端,提供一些基本服务,好比链接处理、受权、安全等.
        2.第二层为mysql提供的一些核心处理内容,好比查询解析、分析、优化等.
        3.第三层则包含了mysql的存储引擎,用于存储和提取存放在mysql中的内容,服务器经过存储引擎API和存储引擎进行通讯,存储引擎不会进行SQL解析(InnoDB是个例外,它会解析外键定义,由于MySQL服务器自身没有实现它),也不会互相通讯,只是简单的响应服务器的请求.
    b.链接管理和安全
        每一个客户链接在服务器上都有本身的线程,每一个链接所属的查询都会在指定的某个单独线程中完成,这些线程轮流的运行在某个cpu上,服务器负责缓存线程,所以没必要为每一个新链接重建或撤销线程.
        当客户端链接到服务器时,服务器要对其进行认证,认证基于用户名、主机、口令,一旦链接成功,客户端就会验证该客户端是否具备执行某个具体查询.
    c.优化与执行
        MySQL会解析查询,并建立一个内部数据结构(解析书),而后进行各类优化.其中包括从新查询、决定查询的读写顺序、以及选择使用的索引等.用户能够经过特殊的关键字给以优化器提示,影响它的决策过程.另外还能够请求服务器给出优化的各类说明,使用户能够知道服务器是如何进行决策的.
        优化器并不关心某个表使用哪一种存储引擎,但存储引擎会对服务器的查询优化有影响.优化器会请求存储引擎为某种具体操做×××能与开销方面的信息以及表内部的统计信息.
        在解析查询之前,服务器会询问查询缓存,它只能保持selelct语句和相应的结果,若是能在缓存中找到要执行的查询,服务器就没必要重新解析、优化、查询.
2、并发控制
    不管什么时候,只要不止一个查询同时修改数据库,都会产生并发控制的问题.
    a.读锁和写锁
        读锁和写锁又分别叫作共享锁和排他锁.
        某一资源上的读锁是共享的或者互不阻塞的,在同一时间里多个用户能够读取同一资源而互不干扰;写锁是排他的,一个写锁会阻塞其余的读锁和写锁.
    b.锁粒度
        任什么时候间里,在给定的资源上,被加锁数据量越小就容许更多的并发操做,只要相互之间互不冲突便可.问题是加锁也会消耗系统资源,每一种锁操做,如得到锁、检查锁是否已解除、解除锁都会增长系统的开销.
        锁策略就是在锁开销和数据安全之间寻求一种平衡,这种平衡也能影响系统性能,每种MySQL存储引擎均可以实现独有的锁策略和锁粒度。如下是两种重要的锁策略
        表锁:表锁是MySQL开销最小的锁策略,它将整个表加锁,当有一个用户进行写操做时,用户会得到一个写锁,写锁会禁止其余用户任何的读写操做,只有无人作写操做时用户才能得到读锁,读锁之间互不冲突.写锁比读锁据用更高的优先级,即便有读操做用户排列在队列中,新申请的写操锁仍然会排在队列的前面(写锁会被安置在读锁以前,而读锁不能排在写锁以前).
        行级锁:行级锁支持最大的并发处理,同时也带来最大的性能开销,行级锁由存储引擎实现而不是MySQL服务器实现
3、事务
     事务是一组原子性的SQL查询语句,也能够看着一个工做单元.事务内的语句要么所有执行要么所有不执行.
     ACID:
     原子性(Atomicity):一个事务必须被视做一个单独的内部不可分的工做单元,以确保一个事务要么所有执行要么所有回滚.
     一致性(Consistency):数据库老是从一种一致性状态转换到另外一种一致性状态,即任何事务处理过程当中做的数据改变都不会影响到数据库的内容.
     隔离性(Isolation):某个事务的处理结果只有在完成以后才对其余事务可见.
     持久性(Durabilit):一旦一个事务提交,事务所作的数据改变将是永久的.
     a.隔离级
        SQL标准定义了4类隔离级,包括了一些具体规则,用来限定事务内外哪些改变是可见的哪些是不可见的.低级别的隔离级通常支持更高的并发处理,并拥有更低的系统开销.
        1.READ UNCOMMITED(读取未提交内容):不多实际应用
        2.READ COMMITED(读取提交内容):大多数系统默认的隔离级,但不是MySQL默认的
        3.REPEATEABLE READ(可重读):MySQL的默认隔离级
        4.SERIALIZABLE(可串行化):
     b.死锁
      死锁是指两个或多个事务在同一资源上互相占有并请求加锁致使的恶性循环,多个事务以不一样的顺序加锁同一资源是就会产生死锁 .
      为了解决这种问题,数据库实现了多种死锁检测和死锁超时机制.对于更复杂的系统,例如InnoDB存储引擎可以预知循环相关性,并马上返回错误(比较好),其余的解决方法是让查询达到一个锁等待超时时间,而后再放弃争用(不够好),目前InnooDB的处理死锁的方法是回滚具备最少排他行级锁的事务(一种对最易回滚事务的估算).
     c.事务日志
     事务日志可使事务处理更加高效.和每次数据一改变就更新数据表的数据不一样,存储引擎能够先更新数据在内存中的拷贝,这很是快,而后存储引擎会将数据改变记录到事务日志,事务日志位于磁盘上,所以具备持久性,这相对较快,由于追加日志致使的写操做只涉及到了磁盘上很小的顺序IO,而替代了写磁盘中表所须要的大量随机IO.最后系统会在某个时间把数据更新到磁盘上的表中.大多存储引擎使用了此技术,也就是一般所说的预写式日志,利用2此磁盘操做将数据写入磁盘.
     
     d.MySQL中的事务
        MySQL中默认操做是AUTOCOMMIT型的,这意味着除非显示的开始一个事务,不然它将每个查询视做一个单独的事务自动执行.能够经过设置变量启用和禁用AUTOCOMMIT
        SHOW VARIABLES LIKE 'AUTOCOMMIT';//查看autocommit的值
        SET AUTOCOMMIT = 1;//修改autocommti的值
        MySQL容许用户经过命令 SET SESSION TRANSATION ISOLATION    LEVEL设置隔离级,新的隔离级将在下一个事物开始时生效.用户也能够在配置文件中为整个服务器设置隔离级;使用下列命令只会为当前事务设置隔离级
        SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITED;
       
        在事务中混合使用事务性表和非事务性表,若是事务回滚,那么在非事务性表上所作的修改将没法取消.
       
        一个事务在任什么时候候均可以得到锁,但只有在commit或rollback的时候才会释放锁,它会同时释放掉全部锁,通常状况下InnoDB的锁定都是隐式锁,InnoDB会根据用户的隔离级别自动出来锁定.InnoDB也支持显示锁定,以下所示：
        SELECT ... LOCK IN SHARE MODE
        SELECT ... FOR UPDATE
       
        MySQL也支持LOCK TABLES 和 UNLOCK TABLES命令,这些命令由MySQL服务器实现,而不是存储引擎.LOCK TABLE命令和事务处理之间的交互是比较复杂的,在某些服务器版本上可能出现一些不可预料的行为,所以,除非是在一个事务中使用LOCK TABLES,同时AUTOCOMMIT模式是被禁止的,不然不管使用何种存储引擎都不要使用LOCK TABLES 命令.
       
四.多版本并发控制
    大多数MySQL的事务性存储引擎,不是简单的使用行加锁机制,而是选用一种叫作多版本并发控制(MVCC)的技术,和行加锁机制关联使用,以应对更多的并发处理问题.如下简单描述InnoDB的简化版的行为方式来讲明MVCC的工做原理:
    InnoDB经过为每一个数据行添加两个隐含值的方式来实现MVCC,这两个隐含值记录了行数据的建立时间和过时时间,每一行都存储了事件发生时的系统版本号用来替代事件发生时的实际时间.每一次开始一个事务,系统版本号会自动增长.每一个事务都会保存它在开始时的"当前系统版本"的记录,而每一个查询都会根据事务的版本号,检查每行数据的版本号.下面是事务隔离级别设置在REPEATABLE READ时,MVCC的实际操做:
    SELECT
        InnoDB检查每行数据,确保它们符合两个标准:1.InnoDB只查找版本早于(<=)当前事务版本号的数据,这确保了当前事务读取的数据都是在事务开始前已经存在的,或者是由当前事务建立或修改的;2.数据行的删除版本必须是未定义的,或是大于事务版本的,这保证了事务读取的行在事务开始时是未被删除的.只用经过了上述两个测试才会被当作查询结果返回.
    INSERT
        InnoDB为每一个行记录当前版本号
    DELETE
        InnoDB为每一个删除行记录删除版本号,做为删除标识.
    UPDATE
        InnoDB为每一个须要更新的行创建一个新的行拷贝,而且为新的行拷贝记录当前的系统版本号,同时也为更新前的旧行记录系统的版本号做为旧的删除版本标识.
    MVCC只工做在REPEATABLE READ和READ COMMITED两个隔离级

五.MySQL的存储引擎
    在文件系统中,MySQL会把每一个数据库保存为数据目录下的一个子目录.当建立一个数据表时,MySQL会在一个和表名同名的,以.frm为后缀的文件中存储表的定义.每种存储引擎对表的数据和索引的存储方式有所不一样,当表的定义是由MySQL服务器独立处理.
    要获知每张表适用何种存储引擎,能够适用命令SHOW TABLE STATUS
    SHOW TABLE STATUS LIKE 'table_name';
   
    a.MyISAM引擎
    MySQL的默认存储引擎,在性能和可用特征之间,MyISAM提供一种良好的平衡,这些特征包括全文检索、压缩、空间函数.MyISAM不支持事务和行级锁.
    存储:
    通常来讲,MyISAM将每一个表存储成两个文件:数据文件和索引文件.两个文件的扩展名分别为.MYD和.MYI,MyISAM的数据文件是平台通用的.
    MyISAM表能够包含动态行和静态行(固定长度行),MySQL会根据表定义决定使用何种行数据.MyISAM表的可容纳的行总数通常只限于数据库服务器的磁盘空间大小,以及操做系统容许建立的最大文件大小.
    MyISAM特性：
    加锁和并发:MyISAM对整张表进行加锁,而不是行.读取程序在读取数据时在全部表上均可以得到共享锁,而写入程序能够得到排他锁.用户在容许select查询时能够在同一张表中插入新行.
    自动修复:MySQL支持对MyISAM表的自动检测和自动修复
    手工修复:用户可使用命令CHECK TABLE table_name 和 REPAIR TABLE table_name 检测表错误并修复表错误,当服务器离线时可使用命令行工具myisamchk检测和修复表.
    索引特性:在MyISAM表中,用户能够基于BLOB或TEXT类型列的前500个字符建立相关索引.MyISAM支持全文索引,它能够根据个别单词为复杂的的搜索选项建立相关索引.
    延迟更新索引:使用表建立选项DELAY_KEY_WRITE建立表时,在查询结束后不会将索引的改变写入磁盘,而是在内存中的键缓存区缓存索引改变数据,它只会在清理缓存数据或关闭表时才将索引数据转储到磁盘.对于数据常常改变而且使用频繁的表,这种模式大大提升了表的处理能力,不过若是服务器或系统崩溃索引必将损坏,并须要修复
    压缩MyISAM表:某些表一旦被建立和填写数据以后,数据将永不改变.这种类型的表很是适合选用压缩的MyISAM表.使用myisampack实用工具能够对表进行压缩,压缩表占有的空间很小使之能够提升更好的处理性能.压缩表也能够拥有索引,但这些索引也是只读的.
   
    b.InnoDB存储引擎
    InnoDB专为事务处理设计的一款存储引擎,特别是用于处理大量短时间事务,短时间事务是指通常能正常完成不需回滚的事务.
    InnoDB将数据存储在一个或几个数据文件之中,这种数据文件通常称之为表空间,表空间本质上是一种"黑盒",在"黑盒"内,InnoDB自我管理一切数据.
    InnoDB使用MVCC机制获取高并发性能,而且实现了全部四个标准隔离级别,它的默认隔离级是REPEATABLE READ,在这个隔离级上,它使用了间隙锁策略防止幻读的产生,不只对查询中读取的行进行加锁,并且还对索引结构中的间隙进行加锁,防止幻影插入.
    InnoDB表是基于聚族索引创建的,InnoDB的索引结构很是不一样于其余大多数MySQL存储引擎,所以它提供了一种很是快速的主键查找性能.不过它的非主键索引也会包含主键列,若是主键定义特别大,其余索引也将和大,若是想在表上定义和多索引则尽可能将主键定义小一些,InnoDB不会压缩处理
    InnoDB不会根据排序创建索引,而MyISAM支持,所以,当InnoDB加载数据和建立索引时会比MyISAM慢不少,任何改变InnoDB表结构的操做会致使整个表的重建包括重建全部索引.
    除了高并发处理能力以外,InnoDB另一个广为人知的特性是它的外键约束,这个特性是MySQL服务器自身都未能提供的
   
    c.表转换
    有几种方法能够将表从一种存储引擎转换成另一种.
    1.ALTER TABLE
    ALTER TABLE table_name ENGINE = InnoDB;
    这种语法适合全部存储引擎,不过这里有一个陷阱:这种转换会耗费大量时间.MySQL要执行一个旧表到新标的逐行复制.
    2.DUMP和IMPORT
    3.CREATE和SELECT