数据库 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> show variables like '%log_bin%'; 查看bin-log是否开启

　　mysql> flush logs; 会多一个最新的bin-log日志

　　mysql> show master status; 查看最后一个bin-log日志的相关信息

　　mysql> reset master; 清空所有的bin-log日志

　

从bin-log恢复数据 恢复全部数据

/usr/bin/mysqlbinlog  --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p superzig-operatingtable-1

恢复指定位置数据

/usr/bin/mysqlbinlog --no-defaults --start-position="74311" --stop-position="74582"  /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p superzig-operatingtable-1

恢复指定时间段数据

/usr/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 --stop-date= "2018-03-02 12:00:00"  --start-date= "2019-03-02 11:55:00"|mysql -uroot -p superzig-operatingtable-1

 

 

 

1. 为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差，因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。

    

    

   binlog:恢复数据库的数据

   redolog：重做 为了保证数据库的持久性，防止commit确认后宕机 数据丢失  是顺序IO 磁盘是随机io.

   undolog:数据回滚

   buffer pool:数据访问快