数据库 sql语句的执行过程
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:恢复数据库的数据 追加写入 逻辑日志记录的是这个语句的原始逻辑，“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数也建议设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
redolog：重做 为了保证数据库的持久性，防止commit确认后宕机 数据丢失 是顺序IO 磁盘是随机io. 物理日志，循环写入，空间固定会用完，记录的是“在某个数据页上做了什么修改”；
InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。
write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。
checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。
innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数建议设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
两阶段提交：将 redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。 为了保证redolog 和 binlog 一致
undolog:数据回滚buffer pool:数据访问快
-
