1.
连接器：
tcp 协议
连接和断开
校验权限、用户名、密码
连接数：show processList; kill show global variables like 'wait _timeout';
默认休眠时间：8小时
连接后，缓存了用户信息，数据库更改了权限等，需要重新登连接才生效
创建用户：create user 'xtc'@'localhost' identified by '123456';
更改用户权限：grant all privileges on *.* to 'xtc'@'localhost';
刷新权限： flush privileges;
更改密码：alter user 'xtc'@'%' identified by '654321';
更改访问权限：update user set host='%' where user='xtc';
查询表结构：describe user;
查询缓存：
查看缓存状态：show global variables like "query_cache_type";
开启缓存 :/etc/mysql/my.cnf 增加 query_cache_type=demand （只有查询中增加 SQL_CACHE 才能命中） off 关闭 默认 on 开启 更改后需要重启
查看命中数量和存储适量 show status like "%Qcache%"
- 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 语句解析成一棵语法树，
优化器： 选择索引
执行器：调用引擎接口
bin-log：
server层 引擎公用
二进制文件
不限大小，追加写入，不会覆盖之前文件
查看是否开启：show global variables like "%log_bin%";
开启：/etc/mysql/my.cnf 增加：
log-bin=/user/local/mysql/data/binlog/mysql-bin 需要给该目录赋予权限
server-id =1 5.7以后需要增加 是唯一标识 自己定义
binlog-format=row #binlog格式，有3种statement 只记录执行 但是效率低 可能会有主从不一致的问题,row 记录sql执行后的结果 效率低 安全性好,mixed 两者结合
sync-binlog=1 #表示每1次执行写入就与硬盘同步，会影响性能，为0时表示，事务提交时mysql不做刷盘操作，由系统决定
会在指定的目录生成mysql-bin-000001文件
查看binlog文件：
/usr/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001
-
为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差，因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。binlog:恢复数据库的数据redolog：重做 为了保证数据库的持久性，防止commit确认后宕机 数据丢失 是顺序IO 磁盘是随机io.undolog:数据回滚buffer pool:数据访问快