mysql基础

一  Mysql的体系结构

          mysql的体系结构从大的方向可以分为4个层次：网络连接层，服务层， 存储引擎层， 系统文件层。

              1  网络连接层 ：客户端连接器，提供与mysql连接的支持，通过设置driver，url， username， password等属性，通过api与数据库连接交互。

              2  服务层：服务层是mysql Server的核心，主要包含系统管理和控制工具，连接池，SQL接口，解析器，查询优化器，和缓存这6个部分。

                      2.1  连接池 ：负责管理数据库客户端与数据库的连接的，一个线程负责管理一个连接。

                      2.2  系统管理和控制工具：负责数据备份恢复，安全管理，集群管理等。

                     2.3  SQL接口 ：用于接收客户端传过来的各种sql命令，然后返回对应的view视图以及sql查询结果。比如DML， DDL， 存储过程，触发器等。

                     2.4  解析器 ：负责将sql语句解析成一颗解析树，然后根据一些mysql的规则，检查解析树是否合法。解析器中有两大部分：语法分析和词法分析。

                     2.5  查询优化器 ：当解析树通过了mysql的语法分析之后，查询优化器会将其转化成最优的执行计划，然后再与存储引擎交互。

                     2.6  缓存 ：缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，权限缓存，引擎缓存等。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。  

               3  存储引擎层 ：存储引擎负责MySQL中数据的存储与提取，与底层系统文件进行交互。MySQL存储引擎是插件式的，服务器中的查询执行引擎通过接口与存储引擎进行通信，接口屏蔽了不同存储引擎之间的差异 。现在有
                                  很多种存储引擎，各有各的特点，最常见的是MyISAM和InnoDB。

               4  系统文件层 :  该层负责将数据库的数据和日志存储在文件系统之上，并完成与存储引擎的交互。是文件的物理存储层。主要包含日志文件，数据文件，配置文件， pid文件， socket文件等。

                     4.1 日志文件 ：
                          4.1.1 错误日志
                               默认开启，show variables like '%log_error%'

                          4.1.2 通用查询日志：
                              记录一般查询语句，show variables like '%general%';

                          4.1.3 二进制日志（binary log）
                              记录了对MySQL数据库执行的更改操作，并且记录了语句的发生时间、执行时长；但是它不记录select、show等不修改数据库的SQL。主要用于数据库恢复和主从复制。
                              show variables like '%log_bin%';  //是否开启
                              show variables like '%binlog%';  //参数查看
                              show binary logs; //查看日志文件

                          4.1.4 慢查询日志（Slow query log）
                              记录所有执行时间超时的查询SQL，默认是10秒。
                              show variables like '%slow_query%'; //是否开启
                              show variables like '%long_query_time%'; //时长

                         4.1.5  配置文件

                              用于存放MySQL所有的配置信息文件，比如my.cnf、my.ini等。   

                         4.1.6  数据文件

                              db.opt 文件：记录这个库的默认使用的字符集和校验规则。
                              frm 文件：存储与表相关的元数据（meta）信息，包括表结构的定义信息等，每一张表都会有一个frm 文件。
                              MYD 文件：MyISAM 存储引擎专用，存放 MyISAM 表的数据（data)，每一张表都会有一个.MYD 文件。
                              MYI 文件：MyISAM 存储引擎专用，存放 MyISAM 表的索引相关信息，每一张 MyISAM 表对应一个 .MYI 文件。
                              ibd文件和 IBDATA 文件：存放 InnoDB 的数据文件（包括索引）。InnoDB 存储引擎有两种表空间方式：独享表空间和共享表空间。独享表空间使用 .ibd 文件来存放数据，且每一张InnoDB 表对应一个 .ibd 文件。共享空                                           间使用 .ibdata 文件，所有表共同使用一个（或多个，自行配置）.ibdata 文件。
                              ibdata1 文件：系统表空间数据文件，存储表元数据、Undo日志等 。
                              ib_logfile0、ib_logfile1 文件：Redo log 日志文件。
                              pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个进程文件，和许多其他 Unix/Linux 服务端程序一样，它存放着自己的进程 id。
                              socket 文件也是在 Unix/Linux 环境下才有的，用户在 Unix/Linux 环境下客户端连接可以不通过TCP/IP 网络而直接使用 Unix Socket 来连接 MySQL。

二  SQL的运行机制

          sql的运行机制如下图所示：

               

            sql的运行流程包含以下几个步骤：

            1  客户端与服务端建立连接，该连接属于“半双工”类型的连接，对于mysql的连接，时刻都有一个线程标志着这个连接正在做什么。
                通讯机制 ：
                       全双工：能同时发送和接收数据，例如平时打电话。
                       半双工：指的某一时刻，要么发送数据，要么接收数据，不能同时。例如早期对讲机
                       单工：只能发送数据或只能接收数据。例如单行道

                线程状态：
                       使用show processlist; 来查看线程的状态。
                       id：线程ID，可以使用kill xx；
                       user：启动这个线程的用户；
                       Host：发送请求的客户端的IP和端口号；
                       db：当前命令在哪个库执行；
                       Command：该线程正在执行的操作命令
                              Create DB：正在创建库操作
                              Drop DB：正在删除库操作
                              Execute：正在执行一个PreparedStatement
                              Close Stmt：正在关闭一个PreparedStatement
                              Query：正在执行一个语句
                              Sleep：正在等待客户端发送语句
                              Quit：正在退出
                              Shutdown：正在关闭服务器
                        Time：表示该线程处于当前状态的时间，单位是秒
                        State：线程状态
                             Updating：正在搜索匹配记录，进行修改
                             Sleeping：正在等待客户端发送新请求
                             Starting：正在执行请求处理
                             Checking table：正在检查数据表
                             Closing table : 正在将表中数据刷新到磁盘中
                             Locked：被其他查询锁住了记录
                             Sending Data：正在处理Select查询，同时将结果发送给客户端
                       Info：一般记录线程执行的语句，默认显示前100个字符。想查看完整的使用show full processlist;

           2  查询缓存（Cache&Buffer)
                    这是MySQL的一个可优化查询的地方，如果开启了查询缓存且在查询缓存过程中查询到完全相同的SQL语句，则将查询结果直接返回给客户端；如果没有开启查询缓存或者没有查询到完全相同的               SQL 语句则会由解析               器进行语法语义解析，并生成“解析树”。
                    缓存Select查询的结果和SQL语句
                    执行Select查询时，先查询缓存，判断是否存在可用的记录集，要求是否完全相同（包括参数值），这样才会匹配缓存数据命中。
                    即使开启查询缓存，以下SQL也不能缓存
                           1  查询语句使用SQL_NO_CACHE
                           2  查询的结果大于query_cache_limit设置
                           3  查询中有一些不确定的参数，比如now()
                    show variables like '%query_cache%'; //查看查询缓存是否启用，空间大小，限制等。
                    show status like 'Qcache%'; //查看更详细的缓存参数，可用缓存空间，缓存块，缓存多少等

             3  解析器
                       解析器（Parser）将客户端发送的SQL进行语法解析，生成"解析树"。预处理器根据一些MySQL规则进一步检查“解析树”是否合法，例如这里将检查数据表和数据列是否存在，还会解析名字和别名，看看它们是否有歧义，最                   后生成新的“解析树”。

             4 查询优化器
                      查询优化器（Optimizer）根据“解析树”生成最优的执行计划。MySQL使用很多优化策略生成最优的执行计划，可以分为两类：静态优化（编译时优化）、动态优化（运行时优化）。
                      等价变换策略：
                          5=5 and a>5 改成 a > 5
                          a < b and a=5 改成b>5 and a=5
                         基于联合索引，调整条件位置等
                     优化count、min、max等函数
                          InnoDB引擎min函数只需要找索引最左边
                          InnoDB引擎max函数只需要找索引最右边
                          MyISAM引擎count(*)，不需要计算，直接返回
                     提前终止查询
                          使用了limit查询，获取limit所需的数据，就不在继续遍历后面数据
                     in的优化
                          MySQL对in查询，会先进行排序，再采用二分法查找数据。比如where id in (2,1,3)，变成 in (1,2,3)

             5 查询执行引擎
                    负责执行 SQL 语句，此时查询执行引擎会根据 SQL 语句中表的存储引擎类型，以及对应的API接口与底层存储引擎缓存或者物理文件的交互，得到查询结果并返回给客户端。若开启用查询缓存，这时会将SQL 语句和结果完整               地保存到查询缓存（Cache&Buffer）中，以后若有相同的 SQL 语句执行则直接返回结果。
                     如果开启了查询缓存，先将查询结果做缓存操作。
                     返回结果过多，采用增量模式返回。

三   MySQL存储引擎

           存储引擎在MySQL的体系架构中位于第三层，负责MySQL中的数据的存储和提取，是与文件打交道的子系统，它是根据MySQL提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引擎。
           使用show engines命令，就可以查看当前数据库支持的引擎信息。 这里我只介绍两种存储引擎：innodb和mysam
           InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全。
           MyISAM：不支持事务和外键，访问速度快。

       3.1 InnoDB和MyISAM对比

              3.1.1  事务和外键

                        InnoDB支持事务和外键，具有安全性和完整性，适合大量insert或update操作。
                        MyISAM不支持事务和外键，它提供高速存储和检索，适合大量的select查询操作。

             3.1.2  锁机制

                        InnoDB支持行级锁，锁定指定记录。基于索引来加锁实现。
                        MyISAM支持表级锁，锁定整张表。

             3.1.3  索引结构

                       InnoDB使用聚集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。
                       MyISAM使用非聚集索引（非聚簇索引），索引和记录分开。

             3.1.4  并发处理能力

                      MyISAM使用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。
                      InnoDB读写阻塞可以与隔离级别有关，可以采用多版本并发控制（MVCC）来支持高并发

             3.1.5  存储文件

                      InnoDB表对应两个文件，一个.frm表结构文件，一个.ibd数据文件。InnoDB表最大支持64TB；
                      MyISAM表对应三个文件，一个.frm表结构文件，一个MYD表数据文件，一个.MYI索引文件。从MySQL5.0开始默认限制是256TB。

             3.1.6   适用场景

                      MyISAM：
                           不需要事务支持（不支持）
                           并发相对较低（锁定机制问题）
                           数据修改相对较少，以读为主
                           数据一致性要求不高
                     InnoDB：
                           需要事务支持（具有较好的事务特性）
                           行级锁定对高并发有很好的适应能力
                           数据更新较为频繁的场景
                           数据一致性要求较高
                           硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，减少磁盘IO。     

四  Innodb的存储结构

         从MySQL 5.5版本开始默认使用InnoDB作为引擎，它擅长处理事务，具有自动崩溃恢复的特性，在日常开发中使用非常广泛。下面是官方的InnoDB引擎架构图，主要分为内存结构和磁盘结构两大部分。Innodb的存储结构示意图如下所示：
                 

      4.1  Innodb的内存结构  

  Innodb的内存结构主要包括Adaptive Hash Index， Buffer Pool，Change Buffer， LogBuffer这      四部分。

          4.1.1  Buffer Pool 

        Buffer Pool：缓存池，是以数据页为单位，默认一页是16K，用于缓存数据库数据以及索引       等，数据存储在缓存池中，当获取数据的时候可以直接从缓存池中去获取，可以减少磁盘IO。       从而提高效率。
               Page分为3大类：
                      Clean：表示在缓存中的数据没有被修改过，与磁盘的数据一致的数据页。
                      Free：表示Buffer Pool 中的空的数据页，没有存放任何数据。
                      Dirty：表示Buffer Pool中的数据有变化，但是数据库里面的还没有被更新，也就是                                  说在Dirty数据页中的数据是跟磁盘的数据是不一致的，需要进行刷盘操作。
               针对这3类Page，Innodb也通过三种链表结构来维护和管理：
                      free list：表示空闲缓冲区，管理free page。
                      flush list:  表示需要刷新到磁盘的缓冲区，管理dirty page，内部的page按照修改的                   时间排序。脏页即存在于flush链表，也在LRU链表，但是两种互补影响，LRU链表负责                   管理page的可用性和释放，而flush链表负责dirty page的刷盘操作。
                      LRU list：表示正在使用的缓存区，管理clean和dirty page。缓冲区以midpoint为界                   限，前面的为new数据缓存区，存放经常访问的数据，占63%；后面的为old区，缓                         存访问较少的数据，占37%。
                改进型LRU算法维护：
                 普通LRU：末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰
                 改性LRU：链表分为new和old两个部分，加入元素时并不是从表头插入，而是从中间
                   midpoint位置插入，如果数据很快被访问，那么page就会向new列表头部移动，如果
                   数据没有被访问，会逐步向old尾部移动，等待淘汰。
                   每当有新的page数据读取到buffer pool时，InnoDb引擎会判断是否有空闲页，是否足
                   够，如果有就将free page从free list列表删除，放入到LRU列表中。没有空闲页，就会
                   根据LRU算法淘汰LRU链表默认的页，将内存空间释放分配给新的页。
              Buffer Pool配置参数
              show variables like '%innodb_page_size%'; //查看page页大小
              show variables like '%innodb_old%'; //查看lru list中old列表参数
              show variables like '%innodb_buffer%'; //查看buffer pool参数
                 建议：将innodb_buffer_pool_size设置为总内存大小的60%-80%，
             innodb_buffer_pool_instances可以设置为多个，这样可以避免缓存争夺。
              Change Buffer：写缓冲区，简称CB。在进行DML操作时，如果BP没有其相应的Page                 数据，并不会立刻将磁盘页加载到缓冲池，而是在CB记录缓冲变更，等未来数据被读取                 时，再将数据合并恢复到BP中。ChangeBuffer占用BufferPool空间，默认占25%，最大允               许占50%，可以根据读写业务量来进行调整。参数innodb_change_buffer_max_size;当更               新一条记录时，该记录在BufferPool存在，直接在BufferPool修改，一次内存操作。如果                 该记录在BufferPool不存在（没有命中），会直接在ChangeBuffer进行一次内存操作，不               用再去磁盘查询数据，避免一次磁盘IO。当下次查询记录时，会先进性磁盘读取，然后再               从ChangeBuffer中读取信息合并，最终载入BufferPool中。
             写缓冲区，仅适用于非唯一普通索引页，为什么？
                如果在索引设置唯一性，在进行修改时，InnoDB必须要做唯一性校验，因此必须查询磁              盘，做一次IO操作。会直接将记录查询到BufferPool中，然后在缓冲池修改，不会在
            ChangeBuffer操作。
             Adaptive Hash Index：自适应哈希索引，用于优化对BP数据的查询。InnoDB存储引擎                会监控对表索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索                  引，所以称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈              希索引。
            Log Buffer：日志缓冲区，用来保存要写入磁盘上log文件（Redo/Undo）的数据，日志缓              冲区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到                  BLOB或多行更新的大事务操作时，增加日志缓冲区可以节省磁盘I/O。
            LogBuffer主要是用于记录InnoDB引擎日志，在DML操作时会产生Redo和Undo日志。
            LogBuffer空间满了，会自动写入磁盘。可以通过将innodb_log_buffer_size参数调大，减少
            磁盘IO频率。
            innodb_flush_log_at_trx_commit参数控制日志刷新行为，默认为1
            0 ： 每隔1秒写日志文件和刷盘操作（写日志文件LogBuffer-->OS cache，刷盘
                   OS cache--  >磁盘文件），最多丢失1秒数据。
            1：事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁IO操作。
            2：事务提交，立刻写日志文件，每隔1秒钟进行刷盘操作。

     4.2  InnoDB磁盘结构

            InnoDB磁盘主要包含Tablespaces，InnoDB Data Dictionary，Doublewrite Buffer、Redo             Log 和 Undo Logs。
            表空间（Tablespaces）：用于存储表结构和数据。表空间又分为系统表空间、独立表空             间、通用表空间、临时表空间、Undo表空间等多种类型；
                  系统表空间（The System Tablespace）:
                     包含InnoDB数据字典，Doublewrite Buffer，Change Buffer，Undo Logs的存储区
                     域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表                       空间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数
                     innodb_data_file_path控制，默认值是ibdata1:12M:autoextend(文件名为ibdata1、                         12MB、自动扩展)。
                 独立表空间（File-Per-Table Tablespaces）:
                     默认开启，独立表空间是一个单表表空间，该表创建于自己的数据文件中，而非创建                       于系统表空间中。当innodb_file_per_table选项开启时，表将被创建于表空间中。否                       则，innodb将被创建于系统表空间中。每个表文件表空间由一个.ibd数据文件代表，                       该文件默认被创建于数据库目录中。表空间的表文件支持动态（dynamic）和压缩
                   （commpressed）行格式。
                通用表空间（General Tablespaces）:
                    通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于
                    mysql数据目录外的其他表空间，其可以容纳多张表，且其支持所有的行格式。
               撤销表空间（Undo Tablespaces）:
                   撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的
                   是System Tablespace共享区，从5.7开始将Undo从System Tablespace分离了出来。
                   InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制，默认为0。参
                   数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、                                   undo_002等。
               临时表空间（Temporary Tablespaces）:
                   分为session temporary tablespaces 和global temporary tablespace两种。                                     session temporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。                         global temporary tablespace储存用户临时表的回滚段（rollback segments ）。mysql                     服务器正常关闭或异常终止时，临时表空间将被移除，每次启动时会被重新创建。
               数据字典（InnoDB Data Dictionary）:
                  InnoDB数据字典由内部系统表组成，这些表包含用于查找表、索引和表字段等对象的                    元数据。元数据物理上位于InnoDB系统表空间中。由于历史原因，数据字典元数据在                    一定程度上与InnoDB表元数据文件（.frm文件）中存储的信息重叠。
               双写缓冲区（Doublewrite Buffer）:
                  位于系统表空间，是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置                        前，会先将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存                    储子系统或mysqld进程崩溃，InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找                      到页面的一个好的备份。在大多数情况下，默认情况下启用双写缓冲区，要禁用                              Doublewrite 缓冲区，可以将innodb_doublewrite设置为0。使用Doublewrite 缓冲区时                    建议将innodb_flush_method设置为O_DIRECT。
                  MySQL的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、
                  刷写模式。有三个值：fdatasync(默认)，O_DSYNC，O_DIRECT。设置O_DIRECT                      表示数据文件写入操作会通知操作系统不要缓存数据，也不要用预读，直接从Innodb
                  Buffer写到磁盘文件。默认的fdatasync意思是先写入操作系统缓存，然后再调用                              fsync() 函数去异步刷数据文件与redo log的缓存信息。
               重做日志（Redo Log) :
                   重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间更正不完整事务写入的数                       据。MySQL以循环方式写入重做日志文件，记录InnoDB中所有对Buffer Pool修改的                       日志。当出现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时                       须redo，重新把数据更新到数据文件。读写事务在执行的过程中，都会不断的产生                         redo log。默认情况下，重做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件                       物理表示。
               撤销日志（Undo Logs）
                    撤消日志是在事务开始之前保存的被修改数据的备份，用于例外情况时回滚事务。撤                      消日志属于逻辑日志，根据每行记录进行记录。撤消日志存在于系统表空间、撤消表                      空间和临时表空间中。

    4.3  mysql的工作线程。

              mysql的工作线程有四种线程组成：Master线程，IO线程，Purge线程，Pager Cleaner线             程。
                

               IO Thread
                        在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据                 库的性能。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer                 和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了。
               read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个
               write thread：负责写操作，将缓存脏页刷新到磁盘。4个
               log thread：负责将日志缓冲区内容刷新到磁盘。1个
               insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个
              Purge Thread
                      事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分               配的undo页。
             show variables like '%innodb_purge_threads%';
             Page Cleaner Thread
                       作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以                 同步数据，又能达到redo log循环使用的目的。会调用write thread线程处理。
             show variables like '%innodb_page_cleaners%';
             Master Thread
                      Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓               冲池中的数据异步刷新到磁盘 ，保证数据的一致性。包含：脏页的刷新（page cleaner                   thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。               内部有两个主处理，分别是每隔1秒和10秒处理。
             每1秒的操作：
                      刷新日志缓冲区，刷到磁盘合并写缓冲区数据，根据IO读写压力来决定是否操作
             刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，
             innodb_io_capacity）
             每10秒的操作：
                      刷新脏页数据到磁盘
                      合并写缓冲区数据
                      刷新日志缓冲区
                      删除无用的undo页

   4.4  Undo Log

             undo log故名思议就是没有做过修改的数据的log，这个log是为了实现事物的原子的产             物，当一个事物处理出现异常等情况需要回滚的时候，这个时候通过undo log可以让数据恢复         到，修改之前的状态。undo log在事物开启前产生，当事物提交之后也不会立马被删除，               innodb是将此时的undo log放入到对应的删除列表中，等待Purge Thread来删除。

            undo log针对MVCC的控制，事物A开启之前，先产生Redo log，同时将修改之前的数据记       录到undo log当中进行备份，此时如果有事物B来读取数据，则从undo log中去读取到对应的           数据，进行快照读。

   4.5  Redo Log和Binlog 

               Redo：顾名思义就是重做。以恢复操作为目的，在数据库发生意外时重现操作。
               Redo Log：指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被          称为重做日志。
               Redo Log 的生成和释放：随着事务操作的执行，就会生成Redo Log，在事务提交时会            将产生Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作            的脏页写入到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用              （被覆盖写入）。
               Binlog日志
               Redo Log 是属于InnoDB引擎所特有的日志，而MySQL Server也有自己的日志，即                Binary  log（二进制日志），简称Binlog。Binlog是记录所有数据库表结构变更以及表数据修          改的二进制日志，不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录，还            包含语句所执行的消耗时间。开启Binlog日志有以下两个最重要的使用场景。
        主从复制：在主库中开启Binlog功能，这样主库就可以把Binlog传递给从库，从库拿到
        Binlog后实现数据恢复达到主从数据一致性。
        数据恢复：通过mysqlbinlog工具来恢复数据。

五   MYSQL的索引。

       索引可以提升查询速度，会影响where查询，以及order by排序。
       从应用层次划分：普通索引、唯一索引、主键索引、复合索引
       从数据存储和索引键值逻辑关系划分：聚集索引（聚簇索引）、非聚集索引（非聚簇索引）
      创建普通索引的方法如下：
             CREATE INDEX <索引的名字> ON tablename (字段名);
             ALTER TABLE tablename ADD INDEX [索引的名字] (字段名);
            CREATE TABLE tablename ( [...], INDEX [索引的名字] (字段名) );
      创建主键索引：
             CREATE TABLE tablename ( [...], PRIMARY KEY (字段名) );
             ALTER TABLE tablename ADD PRIMARY KEY (字段名);
       创建组合索引：
             CREATE INDEX <索引的名字> ON tablename (字段名1，字段名2...);
             ALTER TABLE tablename ADD INDEX [索引的名字] (字段名1，字段名2...);
             CREATE TABLE tablename ( [...], INDEX [索引的名字] (字段名1，字段名2...) );

    5.1 索引的结构

          5.1.1 Hash结构

                    索引的hash结构就是一个hash函数，然后通过某个key计算得到的hash槽，然后在                   对应的hash槽中存放数据。如下图所示：
                      

                   从上图中可以看出，如果是等值查询的话，通过hash函数去计算key值，可以快速的                定位到对应的数据。这种查询的方式很快，但是针对于范围查询的话，hash索引便无能为              力了，只能去全表检索。

          5.1.2 搜索二叉树

                    搜索二叉树就是将数据建成一个有序的平衡二叉树结构。其结构如下图所示：
                   

                     由图中可以看出，搜索二叉树的是的每个节点都存放有对应的数据，然后都有一个                    prev，next节点以及对应的指针，通过这种索引结构可以查询数据的时候使用的是二分                    查找时间复杂度是logN。这种索引结构有两个缺点，第一个就是当数据量比较大                              的时候，树的高度还是会出现很高的情况，查询效率也会有一定的影响；第二个缺点就                  是范围查询，当出现范围查询的时候，查找数据会出现回表的情况，效率也同样不高。

         5.1.3  B树

                     B树是一个有序的平衡多叉树，其结构如下图所示：

                     从图中可以看出B树的相对于搜索二叉树而言，改成了多叉树，从而解决了第一个问                   题，在数据量比较大的时候多叉树的高度也不会特别高。但是B树针对于这种范围查询                   的情况还是没有改善，还是得回表操作。

          5.1.4  B+树

                     B+树是也是一个有序的平衡多叉树，其结构如下图所示：

                     从图中可以看出，B+树在于B树的基础之上做了如下改进，第一个：主键索引中存的                 data 不在是完整的数据，而所有的数据都是存储在叶子节点中，叶子节点通过一个双向                 链表连通。由于叶子节点的数据范围是由索引树定下来的，存在有序性，针对于这种范                   围查询的话，当找到叶子节点的区间，取出区间之间的数据即可，在B树的基础上，避免
               了回表的操作。针对于等值查询，树的高度减少了，所以效率也比较高。当然针对于等                   值查询的话，还是B树的效率比较高，因为B+树必须得找到叶子节点才能找到数据，但                   是B树只要找到对应的节点就可以立即取出数据，不需要再往下去找叶子节点。

      5.2  聚簇索引与非聚簇索引

               聚簇索引：就是将完整的数据和索引存放在一起。

               非聚簇索引：就是在索引的叶子节点里面存放数据的地址。

                     如上图5.1.4中演示的索引就属于聚簇索引，如果将索引叶子节点中的data替换成数                   据在磁盘的地址便是非聚簇索引，在mysql中Innodb引擎就是用的聚簇索引，mysam引                   擎就是用的非聚簇索引。

      5.3  组合索引

               组合索引就是将多个字段一起创建的索引。实际项目中组合索引用处还是比较多的。
               组合索引的使用方法。如基于某表中的a,b,c三个字段建立索引
               3.1 要求查询条件中必须包含组合索引中的第一个字段。
               3.2 可以满足根据a, ab， abc查询的时候都可以使用到索引
               3.3 如果条件中只有b和c条件的话是无法用到索引的。
               3.4 如果条件中只有a和c那么就只有a使用到了索引，c将不会使用到索引。
               3.5 索引的列上一旦使用的计算公式，索引也会失效
               3.6 索引使用了范围查找，那么范围查找之后的索引列也会失效
               3.7 索引字段中使用like,如果like在最左边这该索引列以及其后面的列都会失效。如果在                        右端，则该列后面的索引字段会失效。
               3.8 索引字段中使用了or的话，该列字段及其后面的索引列都会失效。

      5.4 创建索引的原则   

             4.1 经常出现在where条件的字段可以建索引。
             4.2 经常出现在order by 和 group by中的字段可以建索引。
             4.3 经常出现在select语句中少数字段可以考虑建索引。如 select id, a，b, c from  ...  可以                    考虑a,b,c建索引。原因见：mysql之索引数据结构中详解。
             4.4 组合索引的字段先后原则，根据列在sql的条件中出现频率的高低依次排序，频率较高                    的排到最第一位，最低的排到最后一位。

      5.5 最左匹配原则

                复合索引使用时遵循最左前缀原则，最左前缀顾名思义，就是最左优先，即查询中使用             到最左边的列，那么查询就会使用到索引，如果从索引的第二列开始查找，索引将失效。

     5.6 创建优化的建议

             1.表记录很少的不需要建索引（索引是要有存储开销的，同时也会影响到insert和update                     的性能）。
             2.一个表的索引不宜太多。 （每个索引都是一颗B+树，索引太多会占用过多的磁盘空                         间，每次跟新或者插入都要去跟新这些索引的B+树，势必会使得insert和update变慢）
             3. 频繁跟新的字段不建议建索引。 频繁跟新的字段，频繁跟新的字段如果建列索引的                         话，容易出现页裂变和页合并现象，比较消耗DB的性能。
             4. 区分度比较低的字段也不推荐建索引。
             5, 无序字段不建议做索引。
             6, 字段太大不建议建索引。
             7，尽量使用组合索引来代替使用多个单字段索引。

      5.7  执行计划

                mysql的执行计划如下图所示：

                

                type
               表示存储引擎查询数据时采用的方式。比较重要的一个属性，通过它可以判断出查询是                   全表扫描还是基于索引的部分扫描。常用属性值如下，从上至下效率依次增强。
               ALL：表示全表扫描，性能最差。
              index：表示基于索引的全表扫描，先扫描索引再扫描全表数据。
              range：表示使用索引范围查询。使用>、>=、<、<=、in等等。
              ref：表示使用非唯一索引进行单值查询。
              eq_ref：一般情况下出现在多表join查询，表示前面表的每一个记录，都只能匹配后面表                          的一行结果。
             const：表示使用主键或唯一索引做等值查询，常量查询。
             NULL：表示不用访问表，速度最快(索引覆盖)。