内部组件结构

image.png

Server层

image.png
主要功能有：SQL语句的解析、优化，缓存的查询，MySQL内置函数的实现。
1.如果是查询语句，首先会查新缓存是否已有相应结果，有则返回结果，无则进行下一步，如果不是查询语句，同样进行下一步；
2.解析查询，创建一个内部数据结构，解析树，这个解析树主要用来SQL语句的语义与语法解析；
3.优化SQL语句，如：重写查询，决定表的读取顺序，以及选择需要的索引等

连接器

当MySQL启动，等待客户端连接，每一个客户端连接请求，服务器都会新建一个线程处理，如果是线程池的话，则是分配一个空的线程，每个线程独立，拥有各自的内存处理空间。这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。用户的权限表在系统表空间的mysql的user表中。
查询最大连接数：show VARIABLES like ‘%max_connections%’;
连接到服务器，服务器需要对其进行验证，也就是用户名、IP、密码验证，一旦连接成功，还要验证是否具有执行某个特定查询的权限，如：是否允许客户端对某个数据库某个表的某个操作。
数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。
建立连接的过程通常是比较复杂的，所以在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。但是全部使用长连接后，可能会发现，有些时候MySQL占用内存涨得特别快，这是因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接积累下来，可能导致内存占用太大，被系统强行杀掉，从现象看就是MySQL异常重启了。怎么解决这个问题呢？
1、定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
2、如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行mysql_reset_connection 来重新初始化连接资 源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

查询缓存

连接建立完成后，就可以执行 select 语句了。执行逻辑就会来到查询缓存。
MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。

  • 如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。
  • 如果查询命中缓存，MySQL不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

但是大多数情况下不要使用查询缓存。因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。 因此很可能费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如：一个系统配置表，那这张表上的查询才适合使用查询缓存。
查询缓存是否启用：show variable like ‘%query_cache_type%’；——默认不开启
查询缓存大小：show variable like ‘%query_cache_size%’；——默认值1M
MySQL也提供了这种“按需使用”的方式。可以将my.cnf参数query_cache_type设置成DEMAND，这样对于默认的SQL语句都不使用查询缓存。而对于确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样 

  1. select SQL_CACHE * from test where ID=5；

注意：mysql8.0已经移除了查询缓存功能

分析器

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道要做什么，因此需要对 SQL 语句做解析。
分析器先会做词法分析。输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL需要识别出里面的字符串分别是什么，代表什么。
MySQL 从输入的select这个关键字识别出来，这是一个查询语句。它也要把字符串 T 识别成表名 T，把字符串ID识别成列 ID。
做完了这些识别以后，就要做语法分析。根据词法分析的结果，语法分析器会根据语法规则，判断输入的这个 SQL 语句是否满足 MySQL 语法。 如果语句不对，就会收到 You have an error in your SQL syntax 的错误提醒，比如下面这个语句 from 写成了 “rom”。 

select * fro test where id=1;

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds t
o your MySQL server version for the right syntax to use near 'fro test where id=1' at line 1

一般语法错误会提示第一个出现错误的位置，所以要关注的是紧接 use near 的内容

优化器

经过了分析器，MySQL 就知道要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。比如：执行下面这样的语句，这个语句是执行两个表的 join： 

select * from test1 t1 join test2 t2 on t1.id=t2.id where t1.c=10 and t2.d-20;
  • 既可以先从表t1里面取出c=10的记录的值，再根据id值关联到表t2，再判断t2里面d的值是否等于20。
  • 也可以先从表t2里面取出d=20的记录的id值，再根据id值关联到t1，再判断t1里面c的值是否等于10。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

执行器

MySQL通过分析器知道了要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。
开始执行的时候，要先判断一下你对这个表有没有执行查询的权限，如果没有，就会返回没有权限的错误。如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
如：表 test 中，ID 字段没有索引，那么执行器的执行流程是这样的：
1. 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是10，如果不是则跳过，如果是则将这行存在结果集中；
2. 调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
至此，这个语句就执行完成了。
对于有索引的表，执行的逻辑也差不多。第一次调用的是取满足条件的第一行这个接口，之后循环取满足条件的下一行这个接口，这些接口都是引擎中已经定义好的。
在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。
在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟 rows_examined 并不是完全相同的。

日志模块binlog

MySQL整体来看，其实就有两块：一块是Server层，它主要做的是MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。而Server层也有自己的日志，称为binlog，即：归档日志。
binlog是Server层实现的二进制日志文件记录了对MySQL数据库执行更改的所有操作，若操作本身没有导致数据库发生变化，该操作可能也会写入二进制文件。但是不包括select和show这类操作，因为这些操作对数据本身不会进行修改。
binlog的几种作用：

  • 恢复：某些数据的恢复需要binlog，如：在一个数据库全备文件恢复后，用户可以通过binlog文件进行point-in-time的恢复；
  • 复制：其原理与恢复类似，通过复制和执行binlog使一台远程的MySQL数据库与一台MySQL数据库进行实时同步；

log-bin参数：该参数用来控制是否开启binlog日志，默认为关闭，如果想要开启binlog日志的功能，可以在MySQL的配置文件中指定如下的格式：

#配置开启binlog
log‐bin=/usr/local/mysql/data/binlog/mysql‐bin
#注意5.7以及更高版本需要配置本项：server‐id=123454（自定义,保证唯一性）;
#binlog格式，有3种statement,row,mixed
binlog‐format=ROW
#表示每1次执行写入就与硬盘同步，会影响性能，为0时表示，事务提交时mysql不做刷盘操作，由系统决定
sync‐binlog=1

binlog三种模式(row，statement，mixed)
1.row：日志中会记录成每一行数据被修改的形式，而后在其他端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的状况。
优点 在row模式下，binlog中能够不记录执行的sql语句的上下文相关的信息，仅仅只需要记录哪一条记录被修改了，修改为什么样了，因此row的日志内容会很清楚的记录下每一行数据修改的细节，很是容易理解。并且不会出现某些特定状况下的存储过程和函数调用没法被正确复制问题。
缺点 在row模式下，全部的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
2.statement：每一条会修改数据的sql都会记录到binlog中，其他端在复制的时候sql进程会解析成和原来执行相同的sql再执行。
优点 在statement模式下首先就是解决了row模式的缺点，不需要记录每一行数据的变化减小了binlog日志量，节省了I/O以及存储资源，提升性能。
缺点 在statement模式下，因为他是记录的执行语句，因此，为了让这些语句在其他端也能正确执行，那么它还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证全部语句在其他端被执行的时候可以获得相同的结果。子啊statement中，目前已经发现很多状况会形成Mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现。如：sleep() 函数在有些版本中就不能被正确复制，在存储过程当中使用了last_insert_id()函数，可能会使不同端上获得不一致的id等等。因为row是基于每一行来记录的变化，因此不会出现，相似的问题。
3.mixed：从官方文档中看到，以前的MySQL一直都只有基于statement的复制模式，直到5.1.5版本的MySQL才开始支持row复制。从5.0开始，MySQL的复制已经解决了大量老版本中出现的没法正确复制的问题。可是因为存储过程的出现，给MySQL Replication又带来了更大的新挑战。
binlog和InnoDB中的redolog对比：
1.redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用；
2.redo log是物理日志，记录的是在某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，如：给id=2这一行的c字段加1；
3.redo log是循环写的，空间固定会用完；binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

问题一：如何停止一个正在运行的线程？

使用共享变量的方式 在这种方式中，之所以引入共享变量，是因为该变量可以被多个执行相同任务的线程用来作为是否中断的信号，通知中断线程的执行。 使用interrupt方法终止线程 如果一个线程由于等待某些事件的发生而被阻塞，又该怎样停止该线程呢？
这种情况经常会发生，比如当一个线程由于需要等候键盘输入而被阻塞，或者调用Thread.join()方法，或者Thread.sleep()方法，在网络中调用ServerSocket.accept()方法，或者调用了DatagramSocket.receive()方法时，都有可能导致线程阻塞，使线程处于处于不可运行状态时，即使主程序中将该线程的共享变量设置为true，但该线程此时根本无法检查循环标志，当然也就无法立即中断。这里我们给出的建议是，不要使用stop()方法，而是使用Thread提供的interrupt()方法，因为该方法虽然不会中断一个正在运行的线程，但是它可以使一个被阻塞的线程抛出一个中断异常，从而使线程提前结束阻塞状态，退出堵塞代码。

问题二：为什么说Mysql的查询缓存很鸡肋？

因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。

问题三：为什么使用Executor框架比使用应用创建和管理线程好？

每次执行任务创建线程 new Thread()比较消耗性能，创建一个线程是比较耗时、耗资源的。 调用new Thread()创建的线程缺乏管理，被称为野线程，而且可以无限制的创建，线程之间的相互竞争会导致过多占用系统资源而导致系统瘫痪，还有线程之间的频繁交替也会消耗很多系统资源。 直接使用new Thread() 启动的线程不利于扩展，比如定时执行、定期执行、定时定期执行、线程中断等都不便实现。
使用Executor线程池框架的优点 能复用已存在并空闲的线程从而减少线程对象的创建从而减少了消亡线程的开销。 可有效控制最大并发线程数，提高系统资源使用率，同时避免过多资源竞争。 框架中已经有定时、定期、单线程、并发数控制等功能。 综上所述使用线程池框架Executor能更好的管理线程、提供系统资源使用率。

问题四：binlog是什么，怎么使用MySQL的binlog恢复数据

MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复,
mysqlbinlog 语法： mysqlbinlog [options] logfile1 logfile2 …
mysqlbinlog的选项：
-d, —database=name 仅显示指定数据库的转储内容。
-o, —offset=# 跳过前N行的日志条目。
-r, —result-file=name 将输入的文本格式的文件转储到指定的文件。
-s, —short-form 使用简单格式。
—set-charset=name 在转储文件的开头增加’SET NAMES character_set’语句。
—start-datetime=name 转储日志的起始时间。
—stop-datetime=name 转储日志的截止时间。
-j, —start-position=# 转储日志的起始位置。
—stop-position=# 转储日志的截止位置。