MySQL日志详解
发布时间：2023-02-16 13:49:36 所属栏目：MySql 来源：互联网
导读：前言 MySQL日志记录了MysqL数据库日常操作和错误信息。MysqL有不同类型的日志文件（各自存储了不同类型的日志），从日志当中可以查询到MysqL数据库的运行情况、用户的操作、错误的信息等。 MysqL的日志分为以下四大类： 错误日志：记录MysqL服务的启动，运行
|
MysqL> purge master logs before '20180101'; <!--删除2018-01-01之前的日志文件--> 4）通过二进制日志还原MysqL数据 关于通过二进制日志还原的具体过程，还是参考我之前的博文吧！如下： MysqL的备份与恢复详解 3、事务日志 事务日志（InnoDB特有的日志，因为只有Innodb支持事务）可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。 1）查看事务日志的定义 MysqL> show global variables like 'innodb_lo%'; 在上述指令输出的部分内容解释如下： | innodb_flush_log_at_trx_commit | 1 #在事务提交时innodb是否同步日志从缓冲区到文件 中，当这个值为1（默认值）之时，在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新，性能会很差造成大量的磁盘I/O但这种方式最安全；如果设为2,每次提交事务都会写日志，但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒一定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操作，而文件系统是有缓存的，所以这个写入并不能保证数据已经写入到物理磁盘。设置为0，日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。 注：刷写的概念 刷写其实是两个操作，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操作系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操作系统缓存中，操作系统缓存同样指的是内存。并没有实际的持久化数据。 所以，通常设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只是存在于操作系统缓存。之所以说“通常”，可能会有丢失不只1秒的数据的情况，比如说执行flush操作的时候阻塞了。 总结 设为1当然是最安全的，但性能页是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2,如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能。 | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 16777216 | | innodb_log_checksums | ON | | innodb_log_compressed_pages | ON | | innodb_log_file_size | 50331648 #日志文件大小 | | innodb_log_files_in_group | 2 # DB中设置几组事务日志，默认是2 | innodb_log_group_home_dir | ./ #定义innodb事务日志组的位置,此位置设置默认为MysqL的datadir 。 每个事务日志都是大小为50兆的文件（不同版本的MysqL有差异）： 在MysqL中默认以ib_logfile0,ib_logfile1名称存在。 4、慢查询日志（slow query log） 顾名思义，慢查询日志中记录的是执行时间较长的query，也就是我们常说的slow query。 慢查询日志采用的是简单的文本格式，可以通过各种文本编辑器查看其中的内容。其中 记录了语句执行的时刻，执行所消耗的时间，执行用户，连接主机等相关信息。 慢查询日志的作用： 慢查询日志是用来记录执行时间超过指定时间的查询语句。通过慢查询日志，可以查找出哪些查询语句的执行效率很低，以便进行优化。一般建议开启，它对服务器性能的影响微乎其微，但是可以记录MysqL服务器上执行了很长时间的查询语句。可以帮助我们定位性能问题的。MysqL 还提供了专门用来分析满查询日志的工具程序MysqLdumpslow，用来帮助数据库管理人员解决可能存在的性能问题。 1）查看慢查询日志的定义 注：在不同的MysqL版本中，开启慢查询日志参数不太一样，不过都可以通过 show variables like "%slow%" 和show variables like "%long%"查看出来。 MysqL> show global variables like '%slow_query_log%'; <!--查询慢查询日志是否开启--> +---------------------+--------------------------------------+ | Variable_name | Value | +---------------------+--------------------------------------+ | slow_query_log | OFF | <!--OFF为未开启--> | slow_query_log_file | /usr/local/MysqL/data/MysqL-slow.log | +---------------------+--------------------------------------+ <!--上面指定的使慢查询日志的记录的位置--> 2 rows in set (0.01 sec) MysqL> show global variables like '%long%'; <!--查看如何定义语句为慢查询语句--> +----------------------------------------------------------+-----------+ | Variable_name | Value | +----------------------------------------------------------+-----------+ | long_query_time | 10.000000 | | performance_schema_events_stages_history_long_size | 10000 | | performance_schema_events_statements_history_long_size | 10000 | | performance_schema_events_transactions_history_long_size | 10000 | | performance_schema_events_waits_history_long_size | 10000 | +----------------------------------------------------------+-----------+ 5 rows in set (0.00 sec) <!-- 在上面的结果中，long_query_time的值就是慢查询超时时间， 默认为10s，只要执行耗时超过10s的语句就被定义为慢查询语句 --> 2）启动和设置慢查询日志 启动慢查询日志记录： 方法1：通过配置文件my.cnf开启慢查询日志： [root@MysqL ~]# vim /etc/my.cnf #编辑主配置文件，在MysqLd字段下写入以下几行 [MysqLd] slow_query_log=1 # 1表示开启慢查询 slow_query_log_file=/usr/local/MysqL/data/MysqL-slow.log #指定慢查询日志位置 long_query_time=0.0001 #指定超时时间，也就是超过这个时间就会被记录到慢查询日志 slow_launch_time=1 #如果建立线程花费了比这个值更长的时间，slow_launch_threads计数器将增加 [root@MysqL ~]# systemctl restart MysqLd #重启服务使配置生效 再次登录数据库查看相关信息，会发现更改已经生效，如下： MySQL日志详解 方法2：通过登录MysqL服务器直接定义，方式如下： MysqL> set global slow_query_log=1; （编辑：十堰站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
