mysql：

image.png

连接器：

客户端与服务端进行链接，首先拿到输入的host、user、pwd去mysql系统库的系统表校验身份。通过user获取到host与pwd，先校验host，通过了，再校验pwd，校验通过了，都会开辟当前链接的session（会话空间）空间，链接执行的很多的操作，都会在这块内存中，并且会把用户权限全都放到内存里，因为当前客户端每次发送语句，都需要校验权限够不够。

mysql默认长连接8小时，超过8小时就断了
show global variables like “wait_timeout”;
image.png
可以修改此参数： set global wait_timeout=28800;
image.png
如果此时root用户修改了系统表中user表的内容，内存是否能感知到？

  • 不能的，修改后，不能那个刷新当前会话的session空间，所以每次修改后，都需要重启。
  • 执行刷线 flush privileges //刷新数据库 ，在当前情境下，也不会生效

查看当前有多少链接：show processlist;并且能查到当前链接的状态（增删改查等状态）
image.png
关闭连接：kill ID；

查询缓存

执行一个select语句，并不去直接查磁盘文件，而是先去缓存中查询，如果查询到立马返回
默认关闭的，需要开启 mysql < 7 还有此功能， >8版本已经取消此功能
修改此配置的话：

  1. my.cnf
  2. #query_cache_type有3个值 0代表关闭查询缓存OFF，1代表开启ON，2（DEMAND）代表当sql语句中有SQL_CACHE关键词时才缓存
  3. query_cache_type=2

监控查询缓存命中率
image.png
以下说明为复制信息：

  • Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks，如果该值显示较大，则说明查询缓存中的内存碎片过多了，可能在一定的时间进行整理。
  • Qcache_free_memory:查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用，是多了，还是不够用，DBA可以根据实际情况做出调整。
  • Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。
  • Qcache_inserts: 表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果insert到查询缓存中。这样的情况的次数，次数越多，表示查询缓存应用到的比较少，效果也就不理想。当然系统刚启动后，查询缓存是空的，这很正常。
  • Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值，用户可以适当的调整缓存大小。
  • Qcache_not_cached: 表示因为query_cache_type的设置而没有被缓存的查询数量。
  • Qcache_queries_in_cache:当前缓存中缓存的查询数量。
  • Qcache_total_blocks:当前缓存的block数量。

缓存，以sql语句为key，以sql查询的结果集为value， 类似于map结构

但是缓存的存在比较鸡肋，如果查到的数据放到缓存中，后期源数据执行了update语句，缓存中的数据变为脏数据，（因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。），如果需要使用，建议使用在系统配置表或者字典表中，因为这些表可以保持不变，基本不需要修改。

词法分析器

如果缓存没命中，就要执行词法分析器
校验sql，校验sql是否正确是否合法。
把sql拆分，拆分成一棵树，找关键字，按照规则拆，是一个结构化的数据。
image.png

优化器

构建的树之后，where后面的信息字段，查看字段是否使用了索引，会计算使用哪个执行效率更高。走哪个索引并不是我们定的，而是由优化器决定的。
小表join大表

执行器

根据执行器，调用响应的引擎，

bin-log归档（server层）

找回数据的，如果不小心删库，可以通过bin-log归档
bin-log是server层实现二进制的日志，会记录我们所有cud的操作
update最终产生的结果
Binlog有以下几个特点：
1、Binlog在MySQL的Server层实现（引擎共用）
2、Binlog为逻辑日志,记录的是一条语句的原始逻辑
3、Binlog不限大小,追加写入,不会覆盖以前的日志
开启bin-log

  1. 配置开启binlog
  2. log-bin=/usr/local/mysql/data/binlog/mysql-bin#根据自己的配置路径
  3. 注意5.7以及更高版本需要配置本项：server-id=123454（自定义,保证唯一性）;
  4. #binlog格式，有3种statement（记录操作的逻辑本身，有可能主从不一致）,row（推荐，记录sql语句执行的结果）,mixed（前两种方式综合体），效率 statment > row > mixed
  5. binlog-format=ROW
  6. #表示每1次执行写入就与硬盘同步，会影响性能，为0时表示，事务提交时mysql不做刷盘操作，由系统决定
  7. sync-binlog=1

只能找回开启bin-log之后的数据
主从就是利用的bin-log

bin-log命令：

  1. mysql> show variables like '%log_bin%'; 查看bin-log是否开启
  2. mysql> flush logs; 会多一个最新的bin-log日志
  3. mysql> show master status; 查看最后一个bin-log日志的相关信息
  4. mysql> reset master; 清空所有的bin-log日志

查看binlog内容

/usr/local/mysql/bin/mysqlbinlog —no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 查看binlog内容

数据归档操作

  1. #从bin-log恢复数据
  2. #恢复全部数据
  3. /usr/local/mysql/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p tuling(数据库名)
  4. #恢复指定位置数据
  5. /usr/local/mysql/bin/mysqlbinlog --no-defaults --start-position="408" --stop-position="731"  /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p tuling(数据库)
  6. #恢复指定时间段数据
  7. /usr/local/mysql/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 --stop-date= "2022-04-22 12:00:00"  --start-date= "2022-04-28 11:55:00"|mysql -uroot -p test(数据库)