一. MySQL结构
mysql底层结构.png
1. 连接器
1.1 通过连接器使客户端与mysql server层建立连接，流程如下：
（1）由客户端发起请求（长连接/短连接）到连接器
（2）连接器读取Mysql系统中的User表数据，校验请求中的用户名称和密码
（3）校验成功
（4）由连接器开辟一块用于本次会话连接的内存
注：长链接（默认8h）过程中，更新User表中的用户信息，不会对当前已建立的连接造成影响。
连接器工作原理.png
1.2 一些查看mysql连接状态的命令：
（1）show processlist;
查看该数据库实例当前连接列表信息及状态
（2）show global variables like "wait-timeout"
查看最长等待时间
1.3 关于连接器的长/短连接：
开发当中我们大多数时候用的都是长连接,把连接放在Pool内进行管理，但是长连接有些时候会导致MySQL占用内存涨得特别
快，因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如
果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是MySQL异常重启了。
如何解决长连接占用内存不断上升问题：每隔固定时间断开长连接，下次查询时重新进行连接。
2. Mysql缓存
用于暂存查询到的信息，在下次查询到该记录时将直接返回缓存中信息，在内存中以key_value形式进行存储。
注：在Mysql8版本后被优化掉了
（1）开启Mysql缓存
MySQL配置文件中my.cnf
query_cache_type = 2
（2）指定使用查询缓存的语句：关键字SQL_CACHE
select SQL_CACHE * from test where id = 1;
（3）监控查询缓存的命中率
show status like "%Qcache%";
其中指标（Qcache_hits）表示有多少次命中缓存。
我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。
（4）Mysql缓存与磁盘中数据不一致问题：
当用户将记录插入SQL_CACHE，再更新磁盘，会出现磁盘数据与缓存中不一致的问题（缓存适用于储存配置表，字典表等变更较小的数据）
3. MySQL词法分析器
没有命中缓存的SQL语句就要使用词法分析器进行解析了。
词法分析器通过语法分析找到关键词，并一一添加到AstTree(语法树中)
SQL解析流程.png
AstTree.png
4. 优化器
优化器是在表里面有多个索引的时候，决定使用哪个索引；
或者在一个语句有多表关联（join）的时候，决定各个表的连接
顺序。
5. 执行器
执行优化后的SQL语句。在执行前，会进行一次权限的判断，若用户无读写权限，则返回错误；若权限通过，调用设定的引擎执行对应的SQL操作。
6. bin_log记录归档
6.1 特点
bin_log是server层的二进制日志文件，会记录用户的cud操作，有以下几个特点：
（1）Binlog在MySQL的Server层实现（引擎共用）
（2）Binlog为逻辑日志,记录的是一条语句的原始逻辑
（3）Binlog不限大小,追加写入,不会覆盖以前的日志
6.2 bin_log记录方式
开启bin_log日志，配置my.cnf
开启bin_log.png
其中，bin_log提供了三种更新方式。
（1）statement: 记录更新语句本身
（2）row: 记录语句执行后的结果
（3）mixed: 混合(1),(2)中的特性综合记录
6.3 恢复被删除的记录
（1）查看bin_log日志工具
/usr/local/mysql/bin/mysqlbinlog --no -defaults 日志文件路径
（2）恢复指定位置数据
/usr/local/mysql/bin/mysqlbinlog ‐‐no‐defaults
‐‐start‐position="start" ‐‐stop‐position="end" 日志文件路径 |
mysql ‐uroot ‐p 数据库
（3）恢复指定时间范围数据
/usr/local/mysql/bin/mysqlbinlog ‐‐no‐defaults 日志文件路径
‐‐stop‐date="start time" ‐‐start‐date="end time" |
mysql ‐uroot -p 数据库
网友评论