1.Mysql基础架构(基础)

一、前言

select * from T where ID = 1; 我们看到的是一条最简单的输入语句，我们也知道执行后会返回一条结果，但是有没有人了解，这条语句在MYSQL内部的执行过程？所以，今天先和大家一起，打开MYSQL，看一下其中的零件，简单了解一下各个零件的功能，才能便于我们分析、定位复杂的问题。

MySql逻辑架构

①Server 层包括：连接器、查询缓存（8.0之后移除）、分析器、优化器、执行器等；涵盖了MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等）；所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

②存储引擎层：负责数据的存储和提取，其架构模式是插件式的，支持 InnoDB、MyISAM、Memory等多个存储引擎；现在最常用的存储引擎是InnoDB，它从MySql5.5.5版本开始成为了默认存储引擎。比如你执行create table建表脚本的时候，不指定存储引擎，默认使用的就是InnoDB，当然，有特殊需要的话，可以在create table建表脚本中使用engine=memory来指定使用内存引擎创建表。不同存储引擎的表数据存取方式不同，支持的功能也不同。

三、连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令如下：
mysql -h$ip -P$port -u$user –p①(PS①:虽然密码也可以直接跟在-p后面写在命令行中，但这样可能会导致你的密码泄露，如果连的是生产服务器，建议不要这么做。)；
1）经典的TCP握手；
2）连接器则开始认证身份；
3）连接器会到权限表里面查出你拥有的权限②(PS②:之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。)；
4）连接完成③ 查看state ==> show processlist(PS③:连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，可以在show processlist命令（可通过命令行执行或通过客户端查询框数据）中看到，下面的图为show processlist的结果，其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。)；

5）闲置自动断开，由wait_timeout参数控制(8h) ④（PS:④客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数wait_timeout控制的，默认值是 8 小时。如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。）；

长连接：数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。

短连接：短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。建立连接的过程通常是比较复杂的，所以我建议你在使用中要尽量减少建立连接的动作，也就是尽量使用长连接，但是会导致内存增长快⑤（PS⑤:使用长连接后会发现，有时MySQL占用内存涨得特别快；这是因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的，这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是MySQL异常重启了（如果配置了）。），进而导致OOM；

解决方案：

方案1.定期断开长链接（使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。）

方案2.执行mysql_reset_connection（如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。）

四、查询缓存

MySQL拿到一个查询请求后，会优先查询“查询缓存”，查询该语句是否被执行过。之前执行过的语句及其结果可能会以key-value对的形式，被直接缓存在内存中。key是查询的语句，value是查询的结果。
如果你的查询能够直接在这个缓存中找到key，那么这个value就会被直接返回给客户端。如果语句不在查询缓存中，就会继续后面的执行阶段，执行完成后，执行结果会被存入查询缓存中。
如果查询命中缓存，则不需要执行后面的复杂操作，直接返回结果，效率非常高，但大多数情况不建议使用“查询缓存”。
“查询缓存”的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空，可能花费很大成本存储的结果，尚未使用则被更新操作全部清空。对于更新操作较频繁的数据库，查询缓存命中率极低①（PS①:除非业务表仅有少量静态表，且更新频率极低，比如系统配置表，那该表上的查询才适合使用查询缓存。）。
“按需使用”：8.0之前版本可将参数query_cache_type设置成DEMAND，对于默认SQL均不使用，对于需要使用查询缓存的语句，可用SQL_CACHE显式指定：
select SQL_CACHE * from T where ID = 1②（PS②：MySQL8.0版本直接将查询缓存功能模块删除，后续不再提供查询缓存支持。）;

五、分析器

首先，MySQL需要知道你要做什么，因此需要对SQL语句做解析。

1）词法分析

分析器先会做“词法分析”。以上文输入的select为例①（PS①：select * from T where ID = 1;输入的内容是由多个字符串和空格组成的一条SQL语句，MySQL需要识别出里面的字符串分别是什么以及代表什么。），MySQL从输入的“select”关键字识别出该语句是查询语句，同时把字符串“T”识别成“table T”，把字符串“ID”识别成“column ID”。

2）语法分析

做完了这些识别以后，就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断输入的SQL语句是否满足MySQL语法。如果语句不对，会收到“You have an error in your SQL syntax”的错误提醒，一般语法错误会提示第一个出现错误的位置。示例：

elect * from T where ID = 1;ERROR 1064 (42000): You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near②
（PS②：例如上文的select语句少了开头字母“s”，大家可以观察示例，一般语法分析错误只需要关注的是紧接“use near”的内容。） 'elect * from T where ID = 1' at line 1

六、优化器

经过了分析器，MySQL就知道你指令的意图，在开始具体执行之前，还要经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。
示例SQL： select * from T1 join T2 using(ID)①（PS①：using等价于join操作中的on。） where T1.ID = 1 and T2.ID = 2; 既可以先从表T1里面取出ID=1的记录的ID值，再根据ID值关联到表T2，再判断T2里面ID的值是否等于2；也可以先从表T2里面取出ID=2的记录的ID值，再根据ID值关联到表T1，再判断T1里面ID的值是否等于1②（PS②：这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。）。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段③（PS③：如果有优化器是怎么选择索引的，有没有可能选择错等等疑问，我们会在后面的篇幅中展开说明）

七、执行器

MySQL通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。
仍旧以上文select语句为例，开始执行时，优先判断用户对表T有没有执行查询的权限。若无权限，则返回无权限错误①（PS①:如果命中查询缓存，则会在“查询缓存” 返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限。）： ERROR 1142 (42000): SELECT command denied to user 'test'@'localhost' for table 'T' 若有权限，就打开表继续执行②（PS②:打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口）

2.Mysql更新与恢复(基础)

一、前言

前面我们了解了一个查询语句的执行流程，并介绍了执行过程中涉及的处理模块。一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。示例SQL： UPDATE T SET T_NUM = T_NUM + 1 WHERE ID = 1;
一条更新语句的执行流程又是怎样的呢？
查询语句的那一套流程，更新语句也是同样会走一遍；但是又有些许的区别，我们接下来一起来看下具体的区别在哪里。

二、更新语句的执行流程

上篇提及，在表上有更新时，该表相关查询缓存会失效，所以该语句会将表T所有缓存结果清空，这也是一般不建议使用查询缓存的原因。

1.连接数据库——【连接器】 2.清空T表上所有缓存结果——【查询缓存】 3.词法和语法解析得出是更新语句——【分析器】 4.决定使用ID这个索引——【优化器】 5.具体执行，找到这对应行并更新——【执行器】

与查询流程不一样的是，更新流程还涉及两个重要的日志模块：redolog（重做日志）和 binlog（归档日志）

三、redolog（重做日志）

1.秀才的小黑板让我们把镜头切到七侠镇上同福客栈里，一个平平无奇的骂人小天才——吕轻侯(秀才)这个账房先生的身上。大家也知道，他每天的工作要么是记账、要么是记仇。秀才有个小黑板，专门来记仇或者来记录客人的赊账记录。如果揍秀才或者赊账的人不多，秀才就把人名和明细记在小黑板上；但如果是邢捕头带着全镇衙役来集体骗吃骗喝，那秀才的小黑板就写不下了，这时候秀才就会拿出自己专门的小本本；正常情况下，如果有人要赊账或者来还钱，秀才通常有两种做法： 1）翻出账本，找到客人姓名，把赊账的钱增加或者扣减； 2）现在小黑板上记下来，打烊了再掏出账本统一登记；在客栈生意红火的时候，秀才肯定会选择第2）种做法，因为第1）种做法太麻烦了。秀才这小本本少说得有几十页吧，还要先找名字，找到了再拿算盘噼里啪啦，最后再写到小本本上。客人多，秀才每次都翻账本记账，佟掌柜怕不是原地爆炸？

2.MySQL设计者竟然抄作业？如果秀才没有小黑板，每次都翻账本，效率可想而知。同样，MySQL里如果每一次的更新操作都需要写进磁盘，然后磁盘再寻找对应记录再更新，整个过程的IO、查找成本都很高。那MySQL的设计者为了保命就选择了抄秀才的作业，使用了秀才的小黑板机制。

MySQL 的设计者就用了类似秀才小黑板的思路来提升更新效率。而黑板和账本配合的整个过程，其实就是MySQL里经常说到的WAL技术，WAL的全称是Write-AheadLogging，它的关键点就是先写日志，再写磁盘，也就是先写黑板，等不忙的时候再写账本。具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到redolog（黑板）里面，并更新内存，这个时候更新就算完成了。

同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后秀才做的事。如果今天赊账的不多，秀才可以等打烊后再整理。但如果某天赊账的特别多，小黑板写满了，该怎么办呢？

3.该擦黑板了！小黑板写满了，就应该擦掉重写；秀才也是这么做的，当黑板写满，秀才需要把黑板中的一部分赊账记录更新到账本中，然后把这些记录从黑板上擦掉，为记新账腾出空间。同理， InnoDB的redolog是固定大小的，可配置为一组4个文件，每个文件的大小是1GB，那么这块“黑板”总共就可以记录4GB的操作。

write_pos：当前记录的位置，写时后移，文件全部写满后回到初始文件开头；
check_point：当前要擦除的位置，写时后移且循环，擦除前需把记录更新到数据文件；

有了redolog，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe(崩溃安全)①（PS①：要理解crash-safe这个概念，可以想想我们说过的赊账记录的例子。只要赊账记录记在了黑板上或账本上，即使秀才忘记了，比如突然停业几天，恢复生意后依然可以通过账本和黑板上的数据来明确赊账账目。）。在重启mysql服务的时候，根据redolog进行重做，从而达到事务的持久性这一特性。

write_pos和check_point之间的是“黑板”上还空着的部分，可以用来记录新的操作。如果write_pos追上check_point，表示“黑板”满了，此时不再执行新的更新，需要先擦除部分记录，同时推进checkpoint位置。

4.redolog（重做日志）与binlog（归档日志）的概念性比较

binlog是Mysql的Server层日志，主要用于数据误删后进行数据恢复(基于时间点的还原)，另外，主从复制也需要依靠binlog。MySQL在上文讲过，主要有两块，一块是Server层，主要负责MySQL功能层面的事情；一块是引擎层，负责存储相关的具体事宜。上面我们聊到的秀才的黑板即redolog，是InnoDB引擎特有的日志，而Server层自己的日志被称为binlog（归档日志）。

为什么会有两份日志呢？因为最开始MySQL里并没有InnoDB引擎， MySQL自带的引擎是MyISAM，但MyISAM不具备crash-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redolog来实现crash-safe能力。

5.InnoDB引擎执行更新语句的内部执行流程

SQL示例：UPDATE T SET T_NUM = T_NUM + 1 WHERE ID = 1; 内部执行流程： ①执行器先找引擎取ID=1这一行，ID是主键，引擎直接用树搜索找到这一行； ②判断ID=1这一行所在的数据页是否在内存中，在内存则直接返回给执行器； ③不在内存则从磁盘读出行数据，并写入内存再返回给执行器； ④执行器获取到数据引擎返回的行数据并执行计算，此处为将该行数据的T_NUM+1，执行后得到新的一行数据； ⑤得到新数据后，再调用引擎接口写入该行新数据； ⑥引擎将这行新数据更新到内存中；

⑦更新内存的同时，将这个更新操作记录到redolog里面，此时redolog处于PREPARE状态；

⑧redolog记录后会通知执行器完成，随时可提交事务，执行器接到通知会生成该操作的binlog，并把binlog写入磁盘；

⑨执行器调用引擎的提交事务接口，引擎把刚刚写入的redolog改成提交（commit）状态，更新完成。

*后三步中，将redolog的写入拆分成了2个阶段，prepare和commit，即“两阶段提交”。

6.redolog为什么需要两阶段提交？

先用反证法试验一下：仍然用前面的update语句来做例子，假设当前ID=1的行，字段T_NUM的值是0。如果不用两阶段提交，要么就是先写完redolog再写binlog，或者采用反过来的顺序，分别看下会有什么问题。

假设背景：执行update语句过程中，写完第一个日志后，发生crash，第二个日志没有写完。

假设①先写redolog后写binlog，redolog写完，但binlog未写完时，MySQL进程异常重启： redolog写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行T_NUM的值是1；但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句；影响：若需用binlog来恢复临时库，由于这个语句的binlog丢失，临时库会少这次更新，恢复出来的这一行T_NUM的值就是0，与原库的值不同。

假设②先写binlog后写redolog：即binlog 写完，但redolog未写完时，MySQL进程异常重启；由于redolog还没写，崩溃恢复以后这个事务无效，所以这一行T_NUM的值是0；但是binlog里面已经记录了“把T_NUM从0改成1”这个日志；影响：用binlog恢复时多了一个更新出来，恢复出来的这一行T_NUM的值就是1，与原库的值不同。

结论：可见，若不用“两阶段提交”，则数据库状态有可能和用日志恢复出来的库的状态不一致①（PS①：你可能会说，这个概率很低，平时没有频繁需要恢复临时库的场景；其实不然，当你需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，现在常见的做法，也是用全量备份加上应用binlog来实现的，这个“不一致”就会导致你的线上出现主从数据库不一致的情况。）。简单说，redolog和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

7.一些常见log场景或指令

1）崩溃恢复：只要binlog完整，此时崩溃恢复过程会认可这个事务，提交掉。 2）删表如何恢复数据：首先，找最近的全量备份，从这个备份恢复到临时库；然后，从备份时间点开始，将备份的binlog依次取出，重放到中午误删表之前的那个时刻。

binlog默认配置，一般放在/var/lib/mysql

/etc/my.cnf=>log-bin = mysqlbin

binlog日志位置：show variables like '%datadir%';

只查看第一个binlog文件的内容：show binlog events;

查看指定binlog文件的内容：show binlog events in 'mysql-bin.000002'，或者进入日志所在目录 cd /home/mysql/logs/binlogs，输入ls -al 查看需要查看的binlogs产生的时间；

查看当前正在写入的binlog文件：show master status\G;

获取binlog文件列表：show binary logs;

也可以使用mysqlbinlog工具查看，查看方法自行百度。

4.Mysql普通与唯一索引如何选择？(实践)

SQL示例：SELECT ID FROM T WHERE K=5；其中K为索引，ID为主键。

一、查询过程

首先，复习一下索引树查找过程：先通过B+树的树根开始，按层搜索到叶子节点，数据页内通过二分法定位记录。 PS：数据页内部通过有序数组保存节点/数据页之间通过双向链表串接。【普通索引】：查找满足条件的首个记录后，继续查找满足条件的下个记录，直至碰到首个不满足条件记录止，停止检索；【唯一索引】：查找满足条件的首个记录后，停止检索（由于唯一索引定义了唯一性）；性能差距微乎其微：因为InnoDB数据是按数据页为单位读写，当需要读数据时，是以页为将所在数据页单位整体读入内存（默认16KB/页）；当根据K=5查找记录时，其所在页已经全部读入内存，普通索引只需在内存中多一次指针寻找和一次计算；最悲观的情况是K=5的记录是当前页最后一条记录，需取下页数据，读下页操作稍微复杂，对于整型字段，一页可以放近千个KEY，上述概率较低，计算性能差距可忽略不计。

二、更新过程

1.涉及change buffer的概念，什么是change buffer？数据页数据需要更新时，若页在内存则直接更新，否则将“更新操作”缓存在changebuffer，这样更新就不需要再去读该数据页了；当下次查询将数据页读到内存后，执行changebuffer缓存的页相关操作，以这种方式减少磁盘读、提高内存利用率（数据读入内存占用buffer pool）、保证数据逻辑正确性。 PS：以上将change buffer的操作应用到原数据页得到最新结果的过程称为merge，除访问数据页会触发，系统的后台线程会定期merge，shutdown过程中也会执行merge。 merge过程是否会把数据直接写回磁盘？不会。 merge流程：从磁盘读数据页入内存，从changebuffer匹配该数据页的记录并依次应用，写redolog。

2.何时使用change buffer？对于唯一索引，所有更新都要先判断是否违反唯一约束，既然要判断则必然会读入内存，更新内存更快，没必要使用change buffer，故只有普通索引使用change buffer。

3.insert时InnoDB处理流程？以(K,ID)=(4,400)为例。 ①场景1-记录的目标页在内存（非本次重点）：【唯一索引】：找到3~5间位置，判断是否冲突，插入，执行结束；【普通索引】：找到3~5间位置，插入，执行结束； ②场景2-记录的目标页不在内存：【唯一索引】：将数据页读入内存，找到3~5间位置，判断是否冲突，插入，执行结束；【普通索引】：将数据页读入内存，将插入记录在change buffer，执行结束； PS：将数据从磁盘读入内存涉及随机IO访问，是数据库成本最高的操作之一，使用change buffer因为减少了随机磁盘访问，所以对更新性能的提升明显。

4.change buffer适用场景？思考：因为change buffer，只限于普通索引场景下，不适用唯一索引，所有普通索引场景，使用change buffer均可起到加速作用？解析：merge进行数据更新，change buffer缓存记录了页变更动作，数据页merge前，change buffer记录操作数越多，收益越大；结论：写多读少业务change buffer使用效果最好。 PS：读多写少业务场景，满足条件（普通索引、目标数据页不在内存）登记change buffer，因读多写少，merge前即收到读请求，则立即访问数据页，触发merge，随机IO访问不减、反增change buffer维护开销，所以写多读少业务change buffer使用效果最好。

回到开头，通索引和唯一索引，应该怎么选择？查询性能没区别，更新性能差别大，建议尽量选择普通索引。

5.示例（画图更容易理解）向T表insert两条数据（ID1，K1）,（ID2，K2）假设K1在内存，K2不在内存； 5.1：InnoDB buffer pool有两个区，分别是Page1、change buffer； 5.1.1：Page1数据页中有(A,B)(ID1,K1)(C,D) ——①Page1在内存，直接更新内存； PS：5.1.1.1：后台操作(磁盘)data(t.ibd)，其中有所有的Page（Page1、Page2...等等）； 5.1.2：change buffer中记录了add（ID2，K2） to Page2 ——②Page2不在内存，在change buffer记录“要向Page2插入数据”； PS：5.1.1.1：后台操作(系统表空间)system table space(ibdata1)，向内部的change buffer区登记add（ID2，K2） to Page2； 5.2：redo log中的ib-log-fileX中登记： ③add（ID1，K1） to Page1； ④new change buffer item "add（ID2，K2） to Page2"；总体可见，本次insert成本很低，5.1.1与5.1.2写了两次内存，5.2两次操作合在一起写了一次磁盘，另外的后台操作不影响更新时间。 5.3：如果在insert后不久，内存数据还在，发生了针对刚写入K的两个读请求： 5.3.1：读page1直接从内存(InnoDB buffer pool)返回； PS：问题：WAL刷盘前能否正确返回？答案：可以。redo只作为crash-safe，异常重启用平时不用，就算不用到changebuffer也不会用redo，每次数据页不在内存中就直接读盘入内存，然后更新内存数据页才记录redo日记； 5.3.2：读page2需先从磁盘data(t.ibd)读page2入内存，再应用change buffer操作日志；此处change buffer与redo log对比，redo log 主要节省随机写磁盘IO消耗（转成顺序写），而change buffer主要节省随机读磁盘的IO消耗。

小结： 1）普通索引与唯一索引的查询/更新过程； 2）change buffer机制与适用场景； 3）redo log与change buffer差别； 4）根据change buffer适用场景的索引选择；

课后思考：change buffer一开始写内存，如果此时机器断电重启，change buffer是否会丢失？ PS：change buffer一旦丢失，从磁盘读入内存后就不会进行merge，等同于数据丢失。答案：不会丢失，已经在上文给出了答案，redo log里面记录了，崩溃恢复会在恢复回去。