深刻浅出MySQL灵魂十连问，你真的有把握吗？

1、SQL语句执行流程

MySQL大致上可分为Server层和存储引擎层两部分。

Server层：

• 链接器：TCP握手后服务器来验证登录用户身份，A用户建立链接后，管理员对A用户权限修改了也不会影响到已经建立的连接权限，必须从新登录。
• 查询缓存：查询后的结果存储位置，MySQL8.0版本之后已经取消，由于查询缓存失效太频繁，得不偿失。
• 分析器：根据语法规则，判断你输入的这个SQL语句是否知足MySQL语法。
• 优化器：多种执行策略可实现目标，系统自动选择最优进行执行。
• 执行器：判断是否有权限，将最终任务提交到存储引擎。

存储引擎层

负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。如今最经常使用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎(常常用的也是这个)。

SQL执行顺序

2、BinLog、RedoLog、UndoLog

BinLog

BinLog是记录全部数据库表结构变动（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。

STATEMENT 模式

内容：binlog 只会记录可能引发数据变动的 sql 语句

优点：该模式下，由于没有记录实际的数据，因此日志量和 IO 都消耗很低，性能是最优的

劣势：但有些操做并非肯定的，好比 uuid() 函数会随机产生惟一标识，当依赖 binlog 回放时，该操做生成的数据与原数据必然是不一样的，此时可能形成没法预料的后果。

ROW 模式

内容：在该模式下，binlog 会记录每次操做的源数据与修改后的目标数据，StreamSets就要求该模式。

优点：能够绝对精准的还原，从而保证了数据的安全与可靠，而且复制和数据恢复过程能够是并发进行的

劣势：缺点在于 binlog 体积会很是大，同时，对于修改记录多、字段长度大的操做来讲，记录时性能消耗会很严重。阅读的时候也须要特殊指令来进行读取数据。

MIXED 模式

内容：是对上述STATEMENT 跟 ROW  两种模式的混合使用。

细节：对于绝大部分操做，都使用 STATEMENT 来进行 binlog 的记录，只有如下操做使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不肯定函数，使用了 insert delay 语句，使用了临时表

主从同步流程：

一、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。

二、从节点开启一个线程（I/O Thread)把本身扮演成 mysql 的客户端，经过 mysql 协议，请求主节点的二进制日志文件中的事件 。

三、主节点启动一个线程（dump Thread），检查本身二进制日志中的事件，跟对方请求的位置对比，若是不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。

四、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪个二进制日志文件内部的哪个位置（主节点中的二进制文件会有多个）。

五、从节点启动另一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

mysql默认的复制方式是异步的，而且复制的时候是有并行复制能力的。主库把日志发送给从库后无论了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。

1.全同步复制

主库写入binlog后强制同步日志到从库，全部的从库都执行完成后才返回给客户端，可是很显然这个方式的话性能会受到严重影响。

2.半同步复制

半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操做完成。

还能够延伸到因为主从配置不同、主库大事务、从库压力过大、网络震荡等形成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则仍是可用性优先原则？如何判断主库Crash了？互为主备状况下如何避免主备循环复制？被删库跑路了如何正确恢复？(⊙o⊙)… 感受愈来愈扯到DBA的活儿上去了。

RedoLog

能够先经过下面demo理解：

饭点记帐能够把帐单写在帐本上也能够写在粉板上。有人赊帐或者还帐的话，通常有两种作法：

一、直接把帐本翻出来，把此次赊的帐加上去或者扣除掉。

二、先在粉板上记下此次的帐，等打烊之后再把帐本翻出来核算。

生意忙时选后者，由于前者太麻烦了。得在密密麻麻的记录中找到这我的的赊帐总额信息，找到以后再拿出算盘计算，最后再将结果写回到帐本上。

一样在MySQL中若是每一次的更新操做都须要写进磁盘，而后磁盘也要找到对应的那条记录，而后再更新，整个过程IO成本、查找成本都很高。而粉板和帐本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时帐本 = BinLog，粉板 = RedoLog。

一、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个操做记录更新到磁盘里面。

二、 若是更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，而后擦除RedoLog部分数据。RedoLog相似转盘。

RedoLog有write pos 跟checkpoint

write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。

check point：是当前要擦除的位置，也是日后推移而且循环的，擦除记录前要把记录更新到数据文件。

write pos和check point之间的是粉板上还空着的部分，能够用来记录新的操做。若是write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推动一下。

有了redo log，InnoDB就能够保证即便数据库发生异常重启，以前提交的记录都不会丢失，这个能力称为crash-safe。

redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大体以下：

1 prepare阶段 -->  2 写binlog  --> 3 commit

1. 当在2以前崩溃时，重启恢复后发现没有commit，回滚。备份恢复：没有binlog 。一致
2. 当在3以前崩溃时，重启恢复发现虽没有commit，但知足prepare和binlog完整，因此重启后会自动commit。备份：有binlog. 一致

binlog跟redolog区别：

1. redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，全部引擎均可以使用。
2. redo log是物理日志，记录的是在某个数据页上作了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，好比给ID=2这一行的c字段加1。
3. redo log是循环写的，空间固定会用完；binlog是能够追加写入的。追加写是指binlog文件写到必定大小后会切换到下一个，并不会覆盖之前的日志。

UndoLog

UndoLog 通常是逻辑日志，主要分为两种：

1. insert undo log

表明事务在insert新记录时产生的undo log, 只在事务回滚时须要，而且在事务提交后能够被当即丢弃

2. update undo log

事务在进行update或delete时产生的undo log; 不只在事务回滚时须要，在快照读时也须要；因此不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

3、MySQL中的索引

索引的常见模型有哈希表、有序数组和搜索树。

哈希表：一种以KV存储数据的结构，只适合等值查询，不适合范围查询。

有序数组：只适用于静态存储引擎，涉及到插入的时候比较麻烦。能够参考Java中的ArrayList。

搜索树：按照数据结构中的二叉树来存储数据，不过此时是N叉树(B+树)。普遍应用在存储引擎层中。

B+树比B树优点在于：

1. B+ 树非叶子节点存储的只是索引，能够存储的更多。B+树比B树更加矮胖，IO次数更少。
2. B+ 树叶子节点先后管理，更加方便范围查询。同时结果都在叶子节点，查询效率稳定。
3. B+树中更有利于对数据扫描，能够避免B树的回溯扫描。

索引的优势：

一、惟一索引能够保证每一行数据的惟一性 

二、提升查询速度 

三、加速表与表的链接 

四、显著的减小查询中分组和排序的时间

五、经过使用索引，能够在查询的过程当中，使用优化隐藏器，提升系统的性能。

索引的缺点：

一、建立跟维护都须要耗时 

二、建立索引时，须要对表加锁，在锁表的同时，可能会影响到其余的数据操做 

三、 索引须要磁盘的空间进行存储，磁盘占用也很快。

四、当对表中的数据进行CRUD的时，也会触发索引的维护，而维护索引须要时间，可能会下降数据操做性能

索引设计的原则不该该：

一、索引不是越多越好。索引太多，维护索引须要时间跟空间。

二、 频繁更新的数据，不宜建索引。

三、数据量小的表不必创建索引。

应该：

一、重复率小的列建议生成索引。由于重复数据少，索引树查询更有效率，等价基数越大越好。

二、数据具备惟一性，建议生成惟一性索引。在数据库的层面，保证数据正确性 

三、频繁group by、order by的列建议生成索引。能够大幅提升分组和排序效率 

四、常常用于查询条件的字段建议生成索引。经过索引查询，速度更快

索引失效的场景

一、模糊搜索：左模糊或全模糊都会致使索引失效，好比'%a'和'%a%'。可是右模糊是能够利用索引的，好比'a%' 。

二、隐式类型转换：好比select from t where name = xxx , name是字符串类型，可是没有加引号，因此是由MySQL隐式转换的，因此会让索引失效 三、当语句中带有or的时候：好比select from t where name=‘sw’ or age=14

四、不符合联合索引的最左前缀匹配：(A,B,C)的联合索引，你只where了C或B或只有B,C

关于索引的知识点：

主键索引：主键索引的叶子节点存的是整行数据信息。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。主键自增是没法保证彻底自增的哦，遇到惟一键冲突、事务回滚等均可能致使不连续。

惟一索引：以惟一列生成的索引，该列不容许有重复值，但容许有空值(NULL)

普通索引跟惟一索引查询性能：InnoDB的数据是按数据页为单位来读写的，默认每页16KB，所以这两种索引查询数据性能差异微乎其微。

change buffer：普通索引用在更新过程的加速，更新的字段若是在缓存中，若是是普通索引则直接更新便可。若是是惟一索引须要将全部数据读入内存来确保不违背惟一性，因此尽可能用普通索引。

非主键索引：非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）

回表：先经过数据库索引扫描出数据所在的行，再经过行主键id取出索引中未提供的数据，即基于非主键索引的查询须要多扫描一棵索引树。

覆盖索引：若是一个索引包含（或者说覆盖）全部须要查询的字段的值，咱们就称之为覆盖索引。

联合索引：相对单列索引，组合索引是用多个列组合构建的索引，一次性最多联合16个。

最左前缀原则：对多个字段同时创建的组合索引(有顺序，ABC，ACB是彻底不一样的两种联合索引) 以联合索引(a,b,c)为例，创建这样的索引至关于创建了索引a、ab、abc三个索引。另外组合索引实际仍是一个索引，并不是真的建立了多个索引，只是产生的效果等价于产生多个索引。

索引下推：MySQL 5.6引入了索引下推优化，能够在索引遍历过程当中，对索引中包含的字段先作判断，过滤掉不符合条件的记录，减小回表字数。

索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并。增删数据时需考虑页空间利用率。

自增主键：通常会创建与业务无关的自增主键，不会触发叶子节点分裂。

延迟关联：经过使用覆盖索引查询返回须要的主键，再根据主键关联原表得到须要的数据。

InnoDB存储: * .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。*.ibd文件则是该表的索引，数据存储文件，既该表的全部索引树，全部行记录数据都存储在该文件中。

MyISAM存储：* .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。* .MYD文件是MyISAM存储引擎表的全部行数据的文件。* .MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件。MyISAM引擎下，表数据和表索引数据是分开存储的。

MyISAM查询：在MyISAM下，主键索引和辅助键索引都属于非聚簇索引。查询无论是走主键索引，仍是非主键索引，在叶子结点获得的都是目的数据的地址，还须要经过该地址，才能在数据文件中找到目的数据。

PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引

4、SQL事务隔离级别

ACID的四个特性

1. 原子性（Atomicity）：把多个操做放到一个事务中，保证这些操做要么都成功，要么都不成功
2. 一致性（Consistency）：理解成一串对数据进行操做的程序执行下来，不会对数据产生很差的影响，好比凭空产生，或消失
3. 隔离性（Isolation，又称独立性）：隔离性的意思就是多个事务之间互相不干扰，即便是并发事务的状况下，他们只是两个并发执行没有交集，互不影响的东西；固然实现中，也不必定须要这么完整隔离性，即不必定须要这么的互不干扰，有时候仍是容许有部分干扰的。因此MySQL能够支持4种事务隔离性
4. 持久性（Durability）：当某个操做操做完毕了，那么结果就是这样了，而且这个操做会持久化到日志记录中

PS：ACID中C与CAP定理中C的区别

ACID的C着重强调单数据库事务操做时，要保证数据的完整和正确性，数据不会凭空消失跟增长。CAP
理论中的C指的是对一个数据多个备份的读写一致性

事务操做可能会出现的数据问题

一、脏读(dirty read)：B事务更改数据还未提交，A事务已经看到而且用了。B事务若是回滚，则A事务作错了 

二、 不可重复读(non-repeatable read)：不可重复读的重点是修改: 一样的条件, 你读取过的数据, 再次读取出来发现值不同了，只须要锁住知足条件的记录 

三、 幻读(phantom read)：事务A先修改了某个表的全部纪录的状态字段为已处理，未提交；事务B也在此时新增了一条未处理的记录，并提交了；事务A随后查询记录，却发现有一条记录是未处理的形成幻读现象，幻读仅专指新插入的行。幻读会形成语义上的问题跟数据一致性问题。

四、 在可重复读RR隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的。所以，幻读在当前读下才会出现。要用间隙锁解决此问题。

在说隔离级别以前，你首先要知道，你隔离得越严实，效率就会越低。所以不少时候，咱们都要在两者之间寻找一个平衡点。SQL标准的事务隔离级别由低到高以下：

上图从上到下的模式会致使系统的并行性能依次下降，安全性依次提升。

读未提交：别人改数据的事务还没有提交，我在个人事务中也能读到。

读已提交(Oracle默认)：别人改数据的事务已经提交，我在个人事务中才能读到。

可重复读(MySQL默认)：别人改数据的事务已经提交，我在个人事务中也不去读，以此保证重复读一致性。

串行：个人事务还没有提交，别人就别想改数据。

标准跟实现：上面都是关于事务的标准，可是每一种数据库都有不一样的实现，好比MySQL InnDB 默认为RR级别，可是不会出现幻读。由于当事务A更新了全部记录的某个字段，此时事务A会得到对这个表的表锁，由于事务A尚未提交，因此事务A得到的锁没有释放，此时事务B在该表插入新记录，会由于没法得到该表的锁，则致使插入操做被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的操做。因此能够说  MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。

5、MySQL中的锁

不管是Java的并发编程仍是数据库的并发操做都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。

悲观锁：

优势：适合在写多读少的并发环境中使用，虽然没法维持很是高的性能，可是在乐观锁没法提更好的性能前提下，能够作到数据的安全性

缺点：加锁会增长系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用

乐观锁：

优势：在读多写少的并发场景下，能够避免数据库加锁的开销，提升DAO层的响应性能，不少状况下ORM工具都有带有乐观锁的实现，因此这些方法不必定须要咱们人为的去实现。

缺点：在写多读少的并发场景下，即在写操做竞争激烈的状况下，会致使CAS屡次重试，冲突频率太高，致使开销比悲观锁更高。

实现：数据库层面的乐观锁其实跟CAS思想相似， 通数据版本号或者时间戳也能够实现。

数据库并发场景主要有三种：

读-读：不存在任何问题，也不须要并发控制

读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读

写-写：可能存更新丢失问题，好比第一类更新丢失，第二类更新丢失

两类更新丢失问题：

第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果

为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各类锁：

锁分类

MySQL支持三种层级的锁定，分别为

1.表级锁定

MySQL中锁定粒度最大的一种锁，最常使用的MYISAM与INNODB都支持表级锁定。

2.页级锁定

是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，表级锁速度快，但冲突多，行级冲突少，但速度慢。因此取了折衷的页级，一次锁定相邻的一组记录。

3.行级锁定

Mysql中锁定粒度最细的一种锁，表示只针对当前操做的行进行加锁。行级锁能大大减小数据库操做的冲突。其加锁粒度最小，但加锁的开销也最大行级锁不必定比表级锁要好：锁的粒度越细，代价越高，相比表级锁在表的头部直接加锁，行级锁还要扫描找到对应的行对其上锁，这样的代价实际上是比较高的，因此表锁和行锁各有所长。

MyISAM中的锁

1. 虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。因此MyISAM的加锁相对比较开销低，但数据操做的并发性能相对就不高。但若是写操做都是尾插入，那仍是能够支持必定程度的读写并发

2. 从MyISAM所支持的锁中也能够看出，MyISAM是一个支持读读并发，但不支持通用读写并发，写写并发的数据库引擎，因此它更适合用于读多写少的应用场合，通常工程中也用的较少。

InnoDB中的锁

该模式下支持的锁实在是太多了，具体以下：

共享锁和排他锁 (Shared and Exclusive Locks)

意向锁（Intention Locks） 

记录锁（Record Locks） 

间隙锁（Gap Locks） 

临键锁 （Next-Key Locks） 

插入意向锁（Insert Intention Locks） 

主键自增锁 (AUTO-INC Locks) 

空间索引断言锁（Predicate Locks for Spatial Indexes）

举个栗子，好比行锁里的共享锁跟排它锁：lock in share modle 共享读锁：

为了确保本身查到的数据没有被其余的事务正在修改，也就是说确保查到的数据是最新的数据，而且不容许其余人来修改数据。可是本身不必定可以修改数据，由于有可能其余的事务也对这些数据使用了 in share mode 的方式上了S 锁。若是不及时的commit 或者rollback 也可能会形成大量的事务等待。

for update排它写锁:

为了让本身查到的数据确保是最新数据，而且查到后的数据只容许本身来修改的时候，须要用到for update。至关于一个 update 语句。在业务繁忙的状况下，若是事务没有及时的commit或者rollback 可能会形成其余事务长时间的等待，从而影响数据库的并发使用效率。

Gap Lock间隙锁：

一、行锁只能锁住行，若是在记录之间的间隙插入数据就没法解决了，所以MySQL引入了间隙锁(Gap Lock)。间隙锁是左右开区间。间隙锁之间不会冲突。

二、间隙锁和行锁合称NextKeyLock，每一个NextKeyLock是前开后闭区间。

间隙锁加锁原则(学完忘那种)：

一、加锁的基本单位是 NextKeyLock，是前开后闭区间。

二、查找过程当中访问到的对象才会加锁。

三、索引上的等值查询，给惟一索引加锁的时候，NextKeyLock退化为行锁。

四、索引上的等值查询，向右遍历时且最后一个值不知足等值条件的时候，NextKeyLock退化为间隙锁。

五、惟一索引上的范围查询会访问到不知足条件的第一个值为止。

6、MVCC

MVCC：

一、全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的理念，维持一个数据的多个版本，使得读写操做没有冲突。

二、MVCC在MySQL InnoDB中实现目的主要是为了提升数据库并发性能，用更好的方式去处理读-写冲突，作到即便有读写冲突时，也能作到不加锁，非阻塞并发读。

MySQL InnoDB下的当前读和快照读

1.当前读

一、像select lock in share mode(共享锁)、select for update 、update、insert、delete(排他锁)这些操做都是一种当前读，就是它读取的是记录的最新版本，读取时还要保证其余并发事务不能修改当前记录，会对读取的记录进行加锁。

二、当前读能够认为是悲观锁的具体功能实现

2.快照读

一、不加锁的select就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之因此出现快照读的状况，是基于提升并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC，能够认为MVCC是行锁的一个变种，但它在不少状况下，避免了加锁操做，下降了开销；既然是基于多版本，即快照读可能读到的并不必定是数据的最新版本，而有多是以前的历史版本。

二、快照读就是MVCC思想在MySQL的具体非阻塞读功能实现，MVCC的目的就是为了实现读-写冲突不加锁，提升并发读写性能，而这个读指的就是快照读。

三、快照读就是MySQL为咱们实现MVCC理想模型的其中一个具体非阻塞读功能。

由于大佬不满意只让数据库采用悲观锁这样性能不佳的形式去解决读-写冲突问题，而提出了MVCC，因此咱们能够造成两个组合：

MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突

MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突

MVCC的实现原理

MVCC实现原理主要是依赖记录中的 四个隐式字段、undo日志 、Consistent Read View来实现的。

四个隐式字段：

1.DB_TRX_ID：

6byte，最近修改(修改/插入)事务ID：记录建立这条记录/最后一次修改该记录的事务ID

2.DB_ROLL_PTR

7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

3.DB_ROW_ID

6byte，隐含的自增ID（隐藏主键），若是数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

4.FLAG

一个删除flag隐藏字段, 既记录被更新或删除并不表明真的删除，而是删除flag变了

事务对一条记录的修改，会致使该记录的undo log成为一条记录版本线性表(链表)，undo log的链首就是最新的旧记录，链尾就是最先的旧记录。

undo日志：此知识点上文已经说过了，对MVCC有帮助的实质是update undo log，undo log实际上就是存在rollback segment中旧记录链。

一致读视图 Consistent Read View：Read View是事务进行快照读操做的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(InnoDB里面每一个事务有一个惟一的事务ID，叫做transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的)。拿着这个ID跟记录中ID对比进行选择性展现，这里说下大体的思惟。

你能够简单的理解为MVCC为每一行增长了两个隐藏字段，两个字段分别保存了这个行的当前事务ID跟行的删除事务ID。

1.insert时：

InnoDB为新插入的每一行保存当前系统版本号做为版本号。

2.select时：

一、 InnoDB只会查找版本早于当前事务版本的数据行(也就是行的系统版本号<=事务的系统版本号)，这样能够确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

二、行的删除版本要么未定义，要么大于当前事务版本号，这能够确保事务读取到的行在事务开始以前未被删除。

三、只有1，2 同时知足的记录，才能返回做为查询结果。

3.delete时：

InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)做为删除标识.

4.update时：

InnoDB执行update，其实是新插入了一行记录，并保存其建立时间为当前事务的ID，同时保存当前事务ID到要update的行的删除时间。

上面只是一个浅显的讲解MVCC选择标准流程，源码层面应该是根据低水位跟高水位来截取的。具体实现可自行百度。

重点：

一、事务中快照读的结果是很是依赖该事务首次出现快照读的地方，即某个事务中首次出现快照读的地方很是关键，它有决定该事务后续快照读结果的能力。

二、在RC隔离级别下，是每一个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会建立Read View, 以后的快照读获取的都是同一个Read View。

7、缓冲池（buffer pool）

应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。操做系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。MySQL做为一个存储系统，一样具备缓冲池(buffer pool)机制，以免每次查询数据都进行磁盘IO，主要做用：

一、存在的意义是加速查询 

二、缓冲池(buffer pool) 是一种常见的下降磁盘访问 的机制；

三、缓冲池一般以页(page 16K)为单位缓存数据；

四、缓冲池的常见管理算法是LRU，memcache，OS，InnoDB都使用了这种算法；

五、InnoDB对普通LRU进行了优化：将缓冲池分为老生代和新生代，入缓冲池的页，优先进入老生代，该页被访问，才进入新生代，以解决预读失效的问题页被访问。且在老生代停留时间超过配置阈值的，才进入新生代，以解决批量数据访问，大量热数据淘汰的问题

预读失效：

因为预读(Read-Ahead)，提早把页放入了缓冲池，但最终MySQL并无从页中读取数据，称为预读失效

缓冲池污染：

当某一个SQL语句，要批量扫描大量数据时，可能致使把缓冲池的全部页都替换出去，致使大量热数据被换出，MySQL性能急剧降低，这种状况叫缓冲池污染。解决办法：加入老生代停留时间窗口策略后，短期内被大量加载的页，并不会马上插入新生代头部，而是优先淘汰那些，短时间内仅仅访问了一次的页。

8、table瘦身

空洞：

MySQL执行delete命令其实只是把记录的位置，或者数据页标记为了可复用，但磁盘文件的大小是不会变的。经过delete命令是不能回收表空间的。这些能够复用，而没有被使用的空间，看起来就像是空洞。插入时候引起分裂一样会产生空洞。

重建表思路：

一、新建一个跟A表结构相同的表B 

二、按照主键ID将A数据一行行读取同步到表B 

三、用表B替换表A实现效果上的瘦身。

重建表指令：

一、alter table A engine=InnoDB，慎重用，牛逼的DBA都用下面的开源工具。

二、推荐Github：gh-ost

9、SQL Joins、统计、 随机查询

7种join具体以下：

统计：

一、MyISAM模式下把一个表的总行数存在了磁盘上，直接拿来用便可 

二、InnoDB引擎因为 MVCC的缘由，须要把数据读出来而后累计求和 

三、性能来讲 由坏到好：count(字段) < count(主键id) < count(1) ≈ count()，`尽可能用count()便可。`

随机查询：

mysql> select word from words order by rand() limit 3;

直接使用order by rand()，explain 这个语句发现须要 Using temporary和 Using filesort，查询的执行代价每每是比较大的。因此在设计的时要避开这种写法。

mysql> select count(*) into @C from t;
set @Y1 = floor(@C * rand());
set @Y2 = floor(@C * rand());
set @Y3 = floor(@C * rand());
select * from t limit @Y1,1; 
select * from t limit @Y2,1;
select * from t limit @Y3,1;

这样能够避免临时表跟排序的产生，最终查询行数 = C + (Y1+1) + (Y2+1) + (Y3+1)

exist 和 in 对比：

一、in查询时首先查询子查询的表，而后将内表和外表作一个笛卡尔积，而后按照条件进行筛选。

二、子查询使用 exists，会先进行主查询，将查询到的每行数据循环带入子查询校验是否存在，过滤出总体的返回数据。

三、两表大小至关，in 和 exists 差异不大。内表大，用 exists 效率较高；内表小，用 in 效率较高。

四、查询用not in 那么内外表都进行全表扫描，没有用到索引；而not exists 的子查询依然能用到表上的索引。not exists比not in要快。

10、MySQL优化

SQL优化主要分4个方向：SQL语句跟索引、表结构、系统配置、硬件。

总优化思路就是最大化利用索引、尽量避免全表扫描、减小无效数据的查询：

一、减小数据访问：设置合理的字段类型，启用压缩，经过索引访问等减小磁盘 IO。

二、返回更少的数据：只返回须要的字段和数据分页处理，减小磁盘 IO 及网络 IO。

三、减小交互次数：批量 DML 操做，函数存储等减小数据链接次数。

四、减小服务器 CPU 开销：尽可能减小数据库排序操做以及全表查询，减小 CPU 内存占用 。

五、分表分区：使用表分区，能够增长并行操做，更大限度利用 CPU 资源。

SQL语句优化大体举例：

一、合理创建覆盖索引：能够有效减小回表。

二、union，or，in都能命中索引，建议使用in 

三、负向条件(!=、<>、not in、not exists、not like 等) 索引不会使用索引，建议用in。

四、在列上进行运算或使用函数会使索引失效，从而进行全表扫描 

五、当心隐式类型转换，原字符串用整型会触发CAST函数致使索引失效。原int用字符串则会走索引。

六、不建议使用%前缀模糊查询。

七、多表关联查询时，小表在前，大表在后。在 MySQL 中，执行 from 后的表关联查询是从左往右执行的(Oracle 相反)，第一张表会涉及到全表扫描。

八、调整 Where 字句中的链接顺序，MySQL 采用从左往右，自上而下的顺序解析 where 子句。根据这个原理，应将过滤数据多的条件往前放，最快速度缩小结果集。

SQL调优大体思路：

一、先用慢查询日志定位具体须要优化的sql 

二、使用 explain 执行计划查看索引使用状况 

三、重点关注(通常状况下根据这4列就能找到索引问题)：

一、key（查看有没有使用索引） 

二、key_len（查看索引使用是否充分）

三、type（查看索引类型） 

四、Extra（查看附加信息：排序、临时表、where条件为false等）

四、根据上1步找出的索引问题优化sql 五、再回到第2步

表结构优化：

一、尽可能使用TINYINT、SMALLINT、MEDIUM_INT做为整数类型而非INT，若是非负则加上UNSIGNED 。

二、VARCHAR的长度只分配真正须要的空间 。

三、尽可能使用TIMESTAMP而非DATETIME 。

四、单表不要有太多字段，建议在20之内。

五、避免使用NULL字段，很难查询优化且占用额外索引空间。字符串默认为''。

读写分离：

只在主服务器上写，只在从服务器上读。对应到数据库集群通常都是一主一从、一主多从。业务服务器把须要写的操做都写到主数据库中，读的操做都去从库查询。主库会同步数据到从库保证数据的一致性。通常 读写分离 的实现方式有两种：代码封装跟数据库中间件。

分库分表：分库分表 分为垂直和水平两个方式，通常是先垂直后水平。

一、垂直分库：将应用分为若干模块，好比订单模块、用户模块、商品模块、支付模块等等。其实就是微服务的理念。

二、垂直分表：通常将不经常使用字段跟数据较大的字段作拆分。

三、水平分表：根据场景选择什么字段做分表字段，好比淘宝日订单1000万，用userId做分表字段，数据查询支持到最近6个月的订单，超过6个月的作归档处理，那么6个月的数据量就是18亿，分1024张表，每一个表存200W数据，hash(userId)%100找到对应表格。

四、ID生成器：分布式ID 须要跨库全局惟一方便查询存储-检索数据，确保惟一性跟数字递增性。

目前主要流行的分库分表工具 就是Mycat和sharding-sphere。

TiDB：开源分布式数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具有强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具有以下核心特色

一、支持 MySQL 协议（开发接入成本低）。

二、100% 支持事务（数据一致性实现简单、可靠）。

三、无限水平拓展（没必要考虑分库分表），不停服务。

四、TiDB 支持和 MySQL 的互备。

五、遵循jdbc原则，学习成本低，强关系型，强一致性，不用担忧主从配置，不用考虑分库分表，还能够无缝动态扩展。

适合：

一、原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时，能够考虑使用 TiDB 无缝替换 MySQL。

二、大数据量下，MySQL 复杂查询很慢。

三、大数据量下，数据增加很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。

四、大数据量下，有高并发实时写入、实时查询、实时统计分析的需求。五、有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求。

不适合：

一、单机 MySQL 能知足的场景也用不到 TiDB。

二、数据条数少于 5000w 的场景下一般用不到 TiDB，TiDB 是为大规模的数据场景设计的。

三、若是你的应用数据量小（全部数据千万级别行如下），且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合使用 TiDB。

写在最后

欢迎你们关注个人公众号【风平浪静如码】，海量Java相关文章，学习资料都会在里面更新，整理的资料也会放在里面。

以为写的还不错的就点个赞，加个关注呗！点关注，不迷路，持续更新！！！