MySQL---优化&日志
目录
一、MySQL优化
3、mysql server上的优化
3.1、MySQL查询缓存
3.2、索引和数据缓存
3.2、线程缓存
二、MySQL日志
2.1、redo log 重做日志
2.2、undo log 回滚日志
2.3、错误日志
2.4、查询日志
2.5、二进制日志
2.5.1、基于binlog数据恢复实践操作
六、慢查询日志
一、MySQL优化
1、SQL和索引的优化
2、应用上的优化
3、mysql server上的优化
3.1、MySQL查询缓存
MySQL 的查询缓存是把 select 查询语句上一次的查询结果记录下来放在缓存当中，下一次再查询相同内 容的时候，直接从缓存中取出
来就可以了，不用再进行一遍真正的SQL 查询。但是当两个 select查询中 间出现insert，update，delete 语句的时候，查询缓存就会被
清空。 查询缓存适用更新不频繁的表 ，因 为当表更新频繁的话，查询缓存也总是被清空，过多的查询缓存的数据添加和删除，就会影
响MySQL的 执行效率，还不如每次都从磁盘上查来得快（缓存指的就是一块内存，内存I/O比磁盘 I/O 快很多）。 可以在MySQL 上通
过以下命令，来查看查询缓存的设置：
通过show status命令，可以查看MySQL查询缓存的使用状况，如下：
3.2、索引和数据缓存
主要指的就是 innodb_buffffer_pool_size 配置项，从名字上就能看到，该配置项是针对 InnoDB 存储引擎 起作用的，这个参数定InnoDB
存储引擎的表数据和索引数据的最大内存缓冲区大小。 innodb_buffffer_pool_size是同时为数据块和索引块做缓存，这个值设得越高，
访问表中数据需要的磁 盘 I/O 就越少。
innodb_buffer_pool_size=512M
3.2、线程缓存
主要指配置文件中 thread_cache_size 配置项。给大家讲过 MySQL Server 网络模块采用经典的 I/O 复用
+ 线程池模型，之所以引入线程池，主要就是为了在业务执行的过程中，不会因为临时创建和销毁线
程，造成系统性能降低，因为线程的创建和销毁是很耗费性能的，所以线程池就是在业务使用之前，先
创建一组固定数量的线程，等待事件发生，当有 SQL 请求到达 MySQL Server 的时候，在线程池中取一
个线程来执行该 SQL 请求就可以了，执行完成后，不销毁线程，而是把线程再归还到线程池中，等待下
一次任务的处理（ MySQL 会根据连接量，自动加大线程池的数量）。
thread_cache_size=10
配置完 thread_cache_size ，重启 MySQL Server 服务生效。
二、MySQL日志
2.1、redo log 重做日志
redo log ：重做日志，用于记录事务操作的变化，确保事务的 持久性 。 redo log 是在事务开始后就开始
记录，不管事务是否提交都会记录下来，在异常发生时（如数据持久化过程中掉电）， InnoDB 会使用
redo log 恢复到掉电前的时刻，保证数据的完整性。
MySQL执行的时候都有缓存的辅助，不可能直接和磁盘打交道的
innodb_log_buffffer_size 默认是 16M ，就是 redo log 缓冲区的大小，它随着事务开始，就开始写 redo
log ，如果事务比较大，为了 避免事务执行过程中花费过多磁盘IO ，可以设置比较大的 redo log缓存，节省磁盘IO 。
你
2.2、undo log 回滚日志
undo log ：回滚日志，保存了事务发生之前的数据的一个版本，用于事务执行时的回滚操作，同时也是
实现多版本并发控制（ MVCC ）下读操作的关键技术。
DB_TRX_ID: 事务 ID DB_ROLL_PTR: 回滚指针
2.3、错误日志
错误日志是 MySQL 中最重要的日志之一，它记录了当 mysqld 启动和停止时，以及服务器在运行过程
中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，可以首先查看此日
志。
mysqld 使用错误日志名 host_name.err(host_name 为主机名 ) 并默认在参数 DATADIR( 数据目录 ) 指定
的目录中写入日志文件。
2.4、查询日志
查询日志记录了客户端的所有语句。由于上线项目 sql 特别多，开启查询日志 IO 太多导致 MySQL 效率
低，只有在调试时才开启，比如通过查看 sql 发现热点数据进行缓存。
mysql> show global variables like "%genera%";
2.5、二进制日志
二进制日志 (BINLOG) 记录了所有的 DDL( 数据定义语言 ) 语句和 DML( 数据操纵语言 ) 语句，但是不包括
数据查询语句。语句以 “ 事件 ” 的形式保存，它描述了数据的更改过程。 此日志对于灾难时的数据恢复起
着极其重要的作用。
两个重要的应用场景：主从复制、数据恢复
查看 binlog ： mysql> show binary logs;
通过 mysqlbinlog 工具（ mysql 原生自带的工具）可以快速解析大量的 binlog 日志文件，如：
shell> mysqlbinlog --no-defaults --database=school --base64-output=decode-rows
-v --start-datetime='2021-05-01 00:00:00' --stop-datetime='2021-05-10 00:00:00'
mysql-bin.000001 | more
2.5.1、基于binlog数据恢复实践操作
六、慢查询日志
MySQL 可以设置慢查询日志，当 SQL 执行的时间超过我们设定的时间，那么这些 SQL 就会被记录在慢查
询日志当中，然后我们通过查看日志，用 explain 分析这些 SQL 的执行计划，来判定为什么效率低下，是
没有使用到索引？还是索引本身创建的有问题？或者是索引使用到了，但是由于表的数据量太大，花费
的时间就是很长，那么此时我们可以把表分成 n 个小表，比如订单表按年份分成多个小表等。
慢查询日志相关的参数如下所示：