MySQL日志详解(笔记)
MySQL日志:
查询日志 : 保存系统上的所有查询操作的(不仅仅是SELECT),这是最不应该记录的日志,一个繁忙的服务器查询操作会很多,如果每个都记录,会导致系统性能下降并且带来额外的空间开销,默认关闭,也不建议启用,如果以后需要启用,建议日志记录在数据库中,这样性能会比存在FILE上好.
log={ON|OFF}:是否记录所有语句的日志信息于一般查询日志文件(general_log);
log_output={TABLE|FILE|NONE}
TABLE和FILE可以同时出现,用逗号分隔即可;
general_log:是否启用查询日志;
general_log_file:定义一般查询日志保存的文件
1: mysql> SHOW GLOBAL VARIABLES LIKE ‘%log%‘;
log={ON|OFF}:是否记录所有语句的日志信息于一般查询日志文件(general_log);
log_output={TABLE|FILE|NONE}
TABLE和FILE可以同时出现,用逗号分隔即可;
general_log:是否启用查询日志;
general_log_file:定义一般查询日志保存的文件
注意:需log=ON和general_log=NO同时启用,才会开启查询日志记录功能
开启查询日志功能
执行一条查询语句
去数据目录下查看是否有日志文件
查看该日志类型和内容
设置日志文件记录在数据库中
查看数据库中的日志文件
1: mysql> SELECT * FROM mysql.general_log;2: 使用这个也行,记录一下
慢查询日志:通常要记录下来,查询执行时长超过指定时长的查询,即为慢查询,这个慢不一定是查询语句慢,只要是任何原因导致的查询时间过长,都会记录,慢查询日志通常是拿来定位系统上查询操作执行速度过慢时常用的评估工具,所以通常这个是需要开启的.默认为启用
1: mysql> SHOW GLOBAL VARIABLES LIKE ‘%log%‘;
1: slow_query_log={ON|OFF}2: 设定是否启用慢查询日志;它的输出位置也取决log_output={TABLE|FILE|NONE};3: slow_query_log_file=www-slow.log4: 定义日志文件路径及名称;
设定执行多长时间才算是慢查询
1: mysql> SHOW GLOBAL VARIABLES LIKE ‘long%‘;
1: log_slow_filter=admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk #慢查询要过滤的内容2: log_slow_queries=ON #这是会话变量3: slow_query_log=ON #这是全局变量4: log_slow_rate_limit=1 #记录慢查日志的速率5: log_slow_verbosity #是否记录详细的慢查日志信息,产生的I/O量较大,请自行考虑是否要开启
错误日志 : 不仅记录错误日志,也记录启动过程和关闭过程中的信息,也包括复制线程的相关信息
二进制日志:记录格式是二进制的,里面记录着MySQL中引起数据改变的所有操作或有潜在修改MySQl的操作,只与修改操作有关,复制功能依赖于此日志
错误日志:
服务器启动和关闭过程中的信息;
服务器运行过程中的错误信息;
事件调度器运行一个事件时产生的信息;
在复制架构中的从服务器上启动从服务器线程时产生的信息;
log_error = /path/to/error_log_file
log_warnings = {1|0}
是否记录警告信息于错误日志中;
1: mysql> SHOW GLOBAL VARIABLES LIKE ‘%log%‘;
中继日志:
主服务器的任何能够产生修改的操作,在记录到数据库的同时,也会记录在二进制日志中,从服务器使用
一个用户帐号,不断的向主服务发起请求,去读取二进制日志文件中的每一个条目(事件), 从服务器不断
的把这些二进制文件读到本地来,然后保存在本地日志文件中,逐条读取并执行,这个本地日志文件就叫
中继日志,所以从服务器上的中继日志和主服务器上的二进制日志内容是一样的.因此,从服务器上的二
进制日志建议关闭以提升性能.注:从服务器只能从中继日志读取日志,写入数据,不能执行额外的写操作
事务日志:
事务的主要目的是将随机I/O转换为顺序I/O,并保证事务的兼容性
事务要满足 ACID:持久性
日志文件组:至少应该有两个日志文件,两个日志文件轮替;
事务日志不但要满足持久性,还要满足回滚,如果使用读未提交的隔离等级,A用户未提交修改,此时数据可能在缓存中,也可能在事务日志中,当B用户查询时,他本来是应该查询磁盘文件的,但是A用户并未提交数据,所以B用户查询的地方可能是缓存,也可能是日志文件,因此事务日志要支持读操作,并且,由于B用户可以在缓存或日志文件中搜索数据,所以缓存或日志文件的数据存放格式应该与数据库中的数据存放格式大体相同.想象这样一种场景,如果启动一个非常大的事务,缓存中缓存不下了,就开始写入日志文件中,当第一个日志文件满了,就轮替到第二个日志文件中,同时,第一个日志文件向数据库中写入数据,数据写到一半,,此时,因为某些原因,需要回滚了,那么,已经写入数据库中的数据也需要删除.从此可以想到,如果数据还没到数据库就开始回滚,也就是说回滚点如果是在日志文件中,会快的多,如果回滚点在缓存中,又会更快.此时可以想象,如果单个事务越大,在内存中缓存不下的概率就越大,在日志文件中保存不下的概率也就越大,回滚时的开销也会相应增大,所以,尽可能使用小事务以提升事务引擎的性能,如果单个事务太多啊,也可以考虑拆分大事务.
二进制日志:
时间点恢复
复制
待续...
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。