1.一个查询语句的执行过程
客户端-->连接-->缓存-->解析器-->预处理器-->优化器-->执行计划-->执行引擎-->存储引擎
1.1连接这一块的优化
1.1.1 mysql 服务端增加max_connections ,减少wait_timeout
1.1.2 客户端使用数据库连接池,默认的连接池数量是CPU核心数*2+1
1.2 mysql 缓存默认是关闭的,不推荐使用
1.3 解析器 、预处理器,主要是对词法、语法的解析
1.4 优化器,对语句进行优化,是否使用上索引,会有多种执行计划,选择最优的执行计划进行执行
1.5 执行引擎,使用执行计划去操作存储引擎
1.6存储引擎,存储数据,如innoDB myisam memory...
2.一个修改语句的执行过程
客户端-->innodb buffer pool -->DB
2.1 buffer pool 为了提高读写效率
从磁盘预读一个页(16KB)的数据,放到内存的buffer pool中,buffer pool 默认大小是128M
show VARIABLES like '%innodb_buffer_pool%'
innoDB后台线程会每个一段时间将buffer pool 数据写入磁盘,这个动作就叫做刷脏
2.2 redo log
2.2.1 如果写入数据到了buffer pool ,这时候服务挂了,buffer pool 数据就丢失了,这时候怎么办,redo log就出现了,保证了事务的持久性。
buffer pool 的数据先写到redo log文件中,服务重复后会去读取redo log 将数据写入磁盘.
2.2.2 buffer pool 的数据也不是实时写入redo log,中间也用到了一个 redo log buffer内存缓冲区来提高性能
show VARIABLES like 'innodb_flush_%'
innodb_flush_log_at_trx_commit ,默认为1,每次commit 就将log buffer 数据写入 redo log 中,并刷到磁盘中去。
当设置为0,该模式速度最快,但不太安全,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失
当设置为1,该模式是最安全的, 但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。。
当设置为2,该模式速度较快,也比0安全,只有在操作系统崩溃或者系统断电的情况下,上一秒钟所有事务数据才可能丢失。
2.3 undo log
回滚日志,如果修改数据处理异常,就会执行回滚操作,来保证事务的原子性
name="123" 改成"zhangsan"
udpate user set name="zhangsan" where id=1
1.事务开始,从buffer pool 中读取name="123"的数据,没有的话就从磁盘中读取
2.改写后的数据放到buffer pool
3.name="123" 放到undo log
4.name="zhangsan" 放到redo.log
5.提交事务
3.binlog
mysql的server有一个二进制日志文件,binlog,默认是关闭的,用来记录修改数据,用于主从复制和数据恢复。
从服务器通过读取binlog获取数据,解析成SQL语句写入从服务器中。
show variables like 'log_%';