MySQL优化之——日志

转载请注明出处:http://blog.csdn.net/l1028386804/article/details/46790451

MYSQL里的日志主要分为4类，使用这些日志文件。能够查看MYSQL内部发生的事情。

各自是

1、错误日志：记录mysql服务的启动、执行、停止mysql服务时出现的问题

2、查询日志：记录建立的client连接和运行的语句

3、二进制日志：记录全部更改数据的语句。能够用于数据复制

4、慢查询日志：记录全部运行时间超过long_query_time的全部查询或不使用索引的查询

默认情况下，全部日志创建于mysql数据文件夹中。

通过刷新日志。能够强制mysql关闭和又一次打开日志文件（或者在某些情况下切换到一个新的日志）。当运行一个FLUSH LOGS语句或运行mysqladmin flush-logs 或mysqladmin refresh 时。将刷新日志

假设使用mysql复制功能，在复制server上能够维护很多其它日志文件，这样的日志称为接替日志

其它日志功能会减少mysql数据库的性能。比如。在查询非常频繁的mysql数据库系统中，假设开启了通用查询日志和慢查询日志，mysql数据库会花费非常多时间记录日志。同一时候，日志会占用大量的磁盘空间

---

二进制日志

二进制日志就是我们常常说的binlog，主要记录mysql数据库的变化。

二进制日志以一种有效的格式，而且是事务安全的方式包括更新日志中可用的全部信息。

二进制日志包括关于每一个更新数据库的语句的运行时间信息。他不包括没有改动不论什么数据的语句，比如select语句使用二进制日志的最大目的是最大可能地恢复数据库，由于二进制日志包括备份后进行的全部更新

1、启动和设置二进制日志

默认情况下，二进制日志是关闭的。能够通过改动mysql的配置文件来启动和设置二进制日志

my.ini中[mysqld]组以下有几个设置是关于二进制日志的：

log-bin[=PATH/[FILENAME]]
expire_logs_days=10
max_binlog_size=100M

log-bin定义开启二进制日志；path表明日志文件所在的文件夹路径；

filename指定了日志文件的名称，如文件的全名是filename.0001，filename.0002等

除了上述文件之外，另一个成为filename.index的文件，文件内容为全部日志的清单，能够使用记事本打开该文件

filename.index文件的内容，joe是我的计算机名，当前仅仅有一个binlog文件：.\joe-bin.000001

.\joe-bin.000001

expire_logs_days定义了mysql清除过期日志的时间，即二进制日志自己主动删除的天数。

默认值为0，表示“没有自己主动删除”。当mysql启动或刷新二进制日志时可能删除该文件

max_binlog_size定义了单个文件的限制大小，假设二进制日志写入的内容大小超出给定值，日志就会发生滚动（关闭当前文件，又一次打开一个新的日志文件）。不能将该变量设置为大于1GB或小于4096字节。默认值是1GB

假设正在使用大事务 。二进制日志文件大小还可能超过max_binlog_size的定义大小。

在my.ini配置文件里的[mysqld]组下，加入下面几个參数与參数值

[mysqld]
log-bin
expire_logs_days=10
max_binlog_size=100M

加入完成之后，关闭并重新启动mysql服务进程，就可以打开二进制日志，然后能够通过SHOW VARIABLES语句来查询日志设置

使用show VARIABLES  语句查看日志设置

show VARIABLES  LIKE '%log_%';

能够看到log_bin为ON，max_binlog_size为104857600字节。换算为MB为100MB

MYSQL又一次启动之后，就能够看到新产生的文件后缀为.000001和.index的两个文件。文件名默觉得主机名称

假设想改变日志文件的文件夹位置。能够改动my.ini中log-bin參数

比如：

[mysqld]
log-bin="D:\mysql\log\binlog"

关闭并重新启动mysql服务之后，新的二进制日志将出如今"D:\mysql\log\binlog"路径下

提示：数据库文件最好不要和日志文件放在同一个磁盘上，这样当数据库文件所在磁盘发生损坏的时候。能够使用日志来恢复数据

2、查看二进制日志

mysql二进制日志是经经常使用到的。当mysql创建二进制日志文件时，首先创建一个以filename为名称。以index为后缀的文件；再创建一个以filename为名称。以“.000001”为后缀的文件。

当mysql服务又一次启动一次，以“.000001”为后缀的文件会添加一个。而且后缀名加1递增；假设日志长度超过了max_binlog_size的上限（默认是1GB）也会创建一个新的日志文件show binary logs语句能够查看当前二进制日志文件个数和文件名称。mysql二进制日志并不能直接查看，假设要查看日志内容，能够通过mysqlbinlog命令查看使用show
binary logs语句查看二进制日志文件个数和文件名称

SHOW BINARY LOGS;

能够看到，当前有两个二进制日志文件。由于我把mysql服务重新启动了一次，日志文件的个数和mysql服务启动的次数同样。每启动一次mysql服务，将会产生一个新的日志文件

使用mysqlbinlog查看二进制日志mysqlbinlog是一个单独的exe。须要在命令行里运行我们把binlog文件中面的内容导出到binlog.txt

mysqlbinlog  "D:\Program Files (x86)\MySQL\MySQL Server5.5\data\joe-bin.000002" >c:\binlog.txt

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#140731  7:49:30 server id 1  end_log_pos 107     Start: binlog v 4, server v 5.5.20-log created 140731  7:49:30 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
ioTZUw8BAAAAZwAAAGsAAAABAAQANS41LjIwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACKhNlTEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
'/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

3、删除二进制日志

mysql的二进制日志能够配置自己主动删除。同一时候mysql也提供了安全的手动删除二进制日志的方法

删除全部的二进制日志文件使用RESET MASTER;

RESET MASTER;

运行该语句，全部二进制日志将被删除，mysql 会又一次创建二进制日志，新的日志文件扩展名将又一次从000001開始编号仅仅删除部分二进制日志文件使用PURGE MASTER LOGS;

PURGE MASTER LOGS;

语法例如以下

PURGE {MASTER | BINARY} LOGS TO 'log_name'
PURGE {MASTER | BINARY} LOGS BEFORE 'date'

第一种方法指定文件名称，运行该命令将删除文件名称编号比指定文件名称编号小的全部日志文件

另外一种方法指定日期，运行该命令将删除指定日期曾经的全部日志文件

使用PURGE MASTER LOGS;删除创建时间比binlog.000003早的全部日志文件

首先，为了演示语句操作过程，准备多个日志文件，读者能够对mysql服务进行多次重新启动

比如这里有10个日志文件

运行删除命令

 PURGE MASTER LOGS TO "joe-bin.000003";

运行完毕后。使用 show BINARY logs; 查看二进制日志

能够看到joe-bin.000001和joe-bin.000002两个日志文件被删除了

使用 PURGE MASTER LOGS 删除2013年3月30日前创建的全部日志文件，运行命令例如以下

PURGE MASTER LOGS BEFORE '20130330'

运行完成之后，2013年3月30日前的日志文件都被删除。但2013年3月30日的日志会被保留

4、查看二进制日志里的操作记录

show binlog events;

比方想查看某一个二进制日志里面的记录，但又不想用mysqlbinlog。能够使用show binlog events

比方我想查看'joe-bin.000006'这个binlog文件的内容。运行例如以下命令

show binlog events in 'joe-bin.000006';

内容例如以下

Log_name: joe-bin.000006
Pos: 202
Event_type: Query
Server_id: 1
End_log_pos: 304
Info: use `test`; insert into bin(name) values ('orange') 

能够看到'joe-bin.000006'这个binlog文件记录了哪些SQL命令

假设想知道binlog文件的创建时间。就须要mysqlbinlog工具来查看

C:\ProgramData\MySQL\MySQL Server 5.5\data>mysqlbinlog mysql_bin.000001
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#131015 16:35:56 server id 1  end_log_pos 106

当中131015为日志创建时间，即2013年10月15日

5、使用二进制日志还原数据库

假设mysqlserver启用了二进制日志，在数据库出现意外丢失数据时。能够使用mysqlbinlog工具从指定的时间点開始（比如，最后一次备份）直到如今。或另外一个指定的时间点的日志中恢复数据要想从二进制日志恢复数据，须要知道当前二进制日志文件的路径和文件名称。一般能够从配置文件（即my.cnf或者my.ini，文件名称取决于mysqlserver的操作系统）中找到路径

mysqlbinlog恢复数据的语法例如以下：

mysqlbinlog [option] filename |mysql -uuser -ppass

option是一些可选项，filename是日志文件名称

比較重要的两对option參数是

--start-datetime、--stop-datetime

--start-position、--stop--position

--start-date、--stop-date能够指定恢复数据库的起始时间点和结束时间点

--start-position、--stop--position能够指定恢复数据的開始位置和结束位置

使用mysqlbinlog恢复mysql数据库到2014年7月2日15：27：48时的状态，运行以下命令

mysqlbinlog --stop-datetime="2014-7-2 15:27:48 " D:\mysql\log\binlog\binlog.000008 |mysql -u user -p password

该命令运行成功后。会依据binlog.000008日志文件恢复2014年7月2日15：27：48前的全部操作。这样的方法对误操作的删除数据比較有效

6、临时停止二进制日志

假设在mysql的配置文件配置启动了二进制日志，mysql会一直记录二进制日志。改动配置文件，能够停止二进制日志，可是须要重新启动mysql数据库。mysql提供了临时停止二进制日志的功能。通过 SET SQL_LOG_BIN 语句能够使mysql暂停或者启动二进制日志

语法例如以下

SET sql_log_bin={0|1}

运行以下语句将暂停二进制日志

SET sql_log_bin=0;

运行以下语句将恢复记录二进制日志

SET sql_log_bin=1;

实际上，binlog文件有点类似于SQLSERVER的ldf文件，大家都保存了数据库的操作日志，都能够依据这个日志来恢复数据库可是又有不同，mysql的binlog可用不开启，由于mysql的redo日志放在ib_logfile开头的文件中面，而undo日志跟数据文件是放在一起的所以这一点跟SQLSERVER非常不一样在复制的时候。MYSQL一定要开启binlog能，slave读取binlog。而SQLSERVER的订阅端读取公布端的ldf文件,所以刚才说：binlog文件有点类似于SQLSERVER的ldf文件

---

错误日志

错误日志文件包括了当mysqld启动和停止时，以及server在执行过程中发生不论什么严重错误时的相关信息。

在MYSQL中，错误日志也是很重要的。mysql将启动和停止数据库信息以及一些错误信息记录到错误日志中

1、启动和设置错误日志

在默认情况下，错误日志会记录到数据库的数据文件夹下。

假设没有在配置文件里指定文件名称，则文件名称默觉得hostname.err。

比如：mysql所在server主机名为mysql-db。记录错误信息的文件名称为mysql-db.err。假设运行了FLUSH LOGS。错误日志文件会又一次载入

错误日志的启动和停止以及日志文件名称，都能够通过改动my.ini（或者my.cnf）来配置。错误日志的配置项是log-error。

在[mysqld]下配置log-error，在启动错误日志。

假设须要指定文件名称，则配置项例如以下：

[mysqld]
log-error=[path/[file_name]]

path为日志文件所在的文件夹路径，filename为日志文件名称。改动配置项后，须要重新启动mysql服务才生效

2、查看错误日志

通过错误日志能够监视系统的执行状态，便于及时发现故障，修复故障。

mysql错误日志是以文本文件形式存储的。能够使用文本编辑器直接查看mysql错误日志

假设不知道日志文件的存储路径，能够使用 show variables; 语句查看错误日志的存储路径。

语句例如以下

show variables LIKE 'log_error';

使用记事本查看mysql错误日志

通过上面 show variables LIKE'log_error'; 的语句查看到错误日志的路径。然后用记事本打开该文件

我们能够看到错误日志内容例如以下

140705 16:41:17 [Note] Plugin 'FEDERATED' is disabled.
140705 16:41:17 InnoDB: The InnoDB memory heap is disabled
140705 16:41:17 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140705 16:41:17 InnoDB: Compressed tables use zlib 1.2.3
140705 16:41:17 InnoDB: Initializing buffer pool, size = 2.0G
140705 16:41:18 InnoDB: Completed initialization of buffer pool
InnoDB: The first specified data file E:\MYSQL DataBase\ibdata1 did not exist:
InnoDB: a new database to be created!
140705 16:41:18  InnoDB: Setting file E:\MYSQL DataBase\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
140705 16:41:18  InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 213 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
140705 16:41:21  InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 213 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
140705 16:41:23  InnoDB: Waiting for the background threads to start
140705 16:41:24 InnoDB: 1.1.8 started; log sequence number 0
140705 16:41:24 [Note] Event Scheduler: Loaded 0 events
140705 16:41:24 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140705 23:44:14 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140705 23:44:14 [Note] Event Scheduler: Purging the queue. 0 events
140705 23:44:14  InnoDB: Starting shutdown...
140705 23:44:15  InnoDB: Shutdown completed; log sequence number 1595675
140705 23:44:15 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140706  8:17:09 [Note] Plugin 'FEDERATED' is disabled.
140706  8:17:09 InnoDB: The InnoDB memory heap is disabled
140706  8:17:09 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140706  8:17:09 InnoDB: Compressed tables use zlib 1.2.3
140706  8:17:09 InnoDB: Initializing buffer pool, size = 2.0G
140706  8:17:10 InnoDB: Completed initialization of buffer pool
140706  8:17:10 InnoDB: highest supported file format is Barracuda.
140706  8:17:14  InnoDB: Waiting for the background threads to start
140706  8:17:15 InnoDB: 1.1.8 started; log sequence number 1595675
140706  8:17:16 [Note] Event Scheduler: Loaded 0 events
140706  8:17:16 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140706 14:05:35 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140706 14:05:35 [Note] Event Scheduler: Purging the queue. 0 events
140706 14:05:35  InnoDB: Starting shutdown...
140706 14:05:36  InnoDB: Shutdown completed; log sequence number 1603322
140706 14:05:37 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140718 21:47:03 [Note] Plugin 'FEDERATED' is disabled.
140718 21:47:03 InnoDB: The InnoDB memory heap is disabled
140718 21:47:03 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140718 21:47:03 InnoDB: Compressed tables use zlib 1.2.3
140718 21:47:03 InnoDB: Initializing buffer pool, size = 2.0G
140718 21:47:03 InnoDB: Completed initialization of buffer pool
140718 21:47:03 InnoDB: highest supported file format is Barracuda.
140718 21:47:04  InnoDB: Waiting for the background threads to start
140718 21:47:05 InnoDB: 1.1.8 started; log sequence number 1603322
140718 21:47:06 [Note] Event Scheduler: Loaded 0 events
140718 21:47:06 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140719 20:02:45 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140719 20:02:45 [Note] Event Scheduler: Purging the queue. 0 events
140719 20:02:46  InnoDB: Starting shutdown...
140719 20:02:47  InnoDB: Shutdown completed; log sequence number 1603332
140719 20:02:48 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140719 20:04:20 [Note] Plugin 'FEDERATED' is disabled.
140719 20:04:20 InnoDB: The InnoDB memory heap is disabled
140719 20:04:20 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140719 20:04:20 InnoDB: Compressed tables use zlib 1.2.3
140719 20:04:20 InnoDB: Initializing buffer pool, size = 2.0G
140719 20:04:20 InnoDB: Completed initialization of buffer pool
140719 20:04:20 InnoDB: highest supported file format is Barracuda.
140719 20:04:21  InnoDB: Waiting for the background threads to start
140719 20:04:22 InnoDB: 1.1.8 started; log sequence number 1603332
140719 20:04:23 [Note] Event Scheduler: Loaded 0 events
140719 20:04:23 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140720  1:39:36 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140720  1:39:37 [Note] Event Scheduler: Purging the queue. 0 events
140720  1:39:40  InnoDB: Starting shutdown...
140720 11:17:29 [Note] Plugin 'FEDERATED' is disabled.
140720 11:17:29 InnoDB: The InnoDB memory heap is disabled
140720 11:17:29 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140720 11:17:29 InnoDB: Compressed tables use zlib 1.2.3
140720 11:17:29 InnoDB: Initializing buffer pool, size = 2.0G
140720 11:17:29 InnoDB: Completed initialization of buffer pool
140720 11:17:29 InnoDB: highest supported file format is Barracuda.
140720 11:17:37  InnoDB: Waiting for the background threads to start
140720 11:17:38 InnoDB: 1.1.8 started; log sequence number 1603332
140720 11:17:39 [Note] Event Scheduler: Loaded 0 events
140720 11:17:39 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140720 13:40:21 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140720 13:40:21 [Note] Event Scheduler: Purging the queue. 0 events
140720 13:40:22  InnoDB: Starting shutdown...
140720 13:40:23  InnoDB: Shutdown completed; log sequence number 1603332
140720 13:40:24 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140726 11:12:58 [Note] Plugin 'FEDERATED' is disabled.
140726 11:12:59 InnoDB: The InnoDB memory heap is disabled
140726 11:12:59 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140726 11:12:59 InnoDB: Compressed tables use zlib 1.2.3
140726 11:12:59 InnoDB: Initializing buffer pool, size = 2.0G
140726 11:12:59 InnoDB: Completed initialization of buffer pool
140726 11:12:59 InnoDB: highest supported file format is Barracuda.
140726 11:13:06  InnoDB: Waiting for the background threads to start
140726 11:13:07 InnoDB: 1.1.8 started; log sequence number 1603332
140726 11:13:10 [Note] Event Scheduler: Loaded 0 events
140726 11:13:10 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140727  0:34:19 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140727  0:34:20 [Note] Event Scheduler: Purging the queue. 0 events
140727  0:34:24  InnoDB: Starting shutdown...
140727 10:03:47 [Note] Plugin 'FEDERATED' is disabled.
140727 10:03:49 InnoDB: The InnoDB memory heap is disabled
140727 10:03:49 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140727 10:03:49 InnoDB: Compressed tables use zlib 1.2.3
140727 10:03:49 InnoDB: Initializing buffer pool, size = 2.0G
140727 10:03:49 InnoDB: Completed initialization of buffer pool
140727 10:03:50 InnoDB: highest supported file format is Barracuda.
140727 10:03:50  InnoDB: Waiting for the background threads to start
140727 10:03:51 InnoDB: 1.1.8 started; log sequence number 1603332
140727 10:03:52 [Note] Event Scheduler: Loaded 0 events
140727 10:03:52 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140727 14:29:56 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140727 14:29:56 [Note] Event Scheduler: Purging the queue. 0 events
140727 14:29:58  InnoDB: Starting shutdown...
140727 14:30:00  InnoDB: Shutdown completed; log sequence number 1643538
140727 14:30:00 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140801 21:10:05 [Note] Plugin 'FEDERATED' is disabled.
140801 21:10:05 InnoDB: The InnoDB memory heap is disabled
140801 21:10:05 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140801 21:10:05 InnoDB: Compressed tables use zlib 1.2.3
140801 21:10:06 InnoDB: Initializing buffer pool, size = 2.0G
140801 21:10:06 InnoDB: Completed initialization of buffer pool
140801 21:10:06 InnoDB: highest supported file format is Barracuda.
140801 21:10:09  InnoDB: Waiting for the background threads to start
140801 21:10:10 InnoDB: 1.1.8 started; log sequence number 1643538
140801 21:10:10 [Note] Event Scheduler: Loaded 0 events
140801 21:10:10 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19'  socket: ''  port: 3306  MySQL Community Server (GPL)
140801 22:59:19 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown

140801 22:59:19 [Note] Event Scheduler: Purging the queue. 0 events
140801 22:59:21 [Warning] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Forcing close of thread 2  user: 'root'

140801 22:59:21  InnoDB: Starting shutdown...
140801 22:59:23  InnoDB: Shutdown completed; log sequence number 1643538
140801 22:59:23 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

140801 22:59:24 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=WIN7U-20130414Z-bin' to avoid this problem.
140801 22:59:24 [Note] Plugin 'FEDERATED' is disabled.
140801 22:59:24 InnoDB: The InnoDB memory heap is disabled
140801 22:59:24 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140801 22:59:24 InnoDB: Compressed tables use zlib 1.2.3
140801 22:59:24 InnoDB: Initializing buffer pool, size = 2.0G
140801 22:59:24 InnoDB: Completed initialization of buffer pool
140801 22:59:24 InnoDB: highest supported file format is Barracuda.
140801 22:59:24  InnoDB: Waiting for the background threads to start
140801 22:59:25 InnoDB: 1.1.8 started; log sequence number 1643538
140801 22:59:26 [Note] Event Scheduler: Loaded 0 events
140801 22:59:26 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.19-log'  socket: ''  port: 3306  MySQL Community Server (GPL)

3、删除错误日志

mysql的错误日志以文本文件的形式存储在文件系统中。能够直接删除对于mysql5.5.7曾经的版本号，flush logs能够将错误日志文件重命名为filename.err_old，并创建新的日志文件。

可是从mysql5.5.7開始。flush logs仅仅是又一次打开日志文件。并不做日志备份和创建的操作。假设日志文件不存在。mysql启动或者运行flush logs时会创建新的日志文件在运行状态下删除错误日志文件后。mysql并不会自己主动创建日志文件。flush logs在又一次载入日志的时候，假设文件不存在。则会自己主动创建。所以在删除错误日志之后，假设须要重建日志文件须要在server端运行下面命令：

mysqladmin -u root -p flush-logs

或者在client登录mysql数据库，运行flush logs语句

flush logs;

删除err文件，并用flush logs语句重建log-error文件

手动删除文件

手动运行 flush logs; ，err文件恢复了

打开err文件。里面什么都没有

---

通用查询日志

通用查询日志记录了mysql的全部用户操作，包含启动和关闭服务、运行查询和更新语句等

1、启动和设置通用查询日志

mysqlserver默认情况下并没有开启通用查询日志。假设须要通用查询日志。能够通过改动my.ini或my.cnf配置文件来开启。在my.ini或my.cnf的[mysqld]组下增加log选项

形式例如以下

[mysqld]

log[=path/[filename]]

path为日志文件所在文件夹路径，filename为日志文件名称。

假设不指定文件夹和文件名称。通用查询日志将默认存储在mysql数据文件夹中的hostname.log文件里。hostname是mysql数据库的主机名，这里在[mysqld]以下添加选项log，后面不指定參数值

[mysqld]
log

2、查看通用查询日志

通用查询日志中记录了用的全部操作。通过查看通用查询日志，能够了解用户对mysql进行的操作。通用查询日志是以文本文件形式存储在文件系统中的。能够使用文本编辑器直接打开通用日志文件进行查看。Windows下能够使用记事本Linux下能够使用vim、gedit等使用记事本查看mysql通用查询日志

文件内容例如以下

E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld, Version: 5.5.19-log (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: (null)
Time                 Id Command    Argument
140801 23:39:33        1 Connect    root@localhost on
            1 Query    SHOW VARIABLES
            1 Query    SHOW WARNINGS
            1 Query    select timediff( curtime(), utc_time() )
            1 Query    SHOW COLLATION
            1 Query    SET NAMES utf8
            1 Query    SET character_set_results=NULL
            1 Query    SELECT * FROM `emp`
140801 23:39:44        1 Query    SELECT * FROM `emp`
            1 Query    SELECT * FROM `emp`
140801 23:39:55        1 Query    USE test;

SELECT * FROM `emp`
            1 Init DB    test

能够看到mysql启动信息和用户root连接server与运行查询语句的记录

3、删除通用查询日志

通用查询日志是以文本文件的形式存储在文件系统中的。通用查询日志记录用户的全部操作因此在用户查询、更新频繁的情况下，通用查询日志会增长得非常快。DBA能够定期删除比較早的通用日志。以节省磁盘空间。能够用直接删除日志文件的方式删除通用查询日志。要又一次建立新的日志文件。可使用语句

mysqladmin -flush logs

直接删除log文件

运行 flush logs

log文件又一次生成了

---

慢查询日志

慢查询日志是记录查询时长超过指定时间的日。

慢查询日志主要用来记录运行时间较长的查询语句通过慢查询日志，能够找出运行时间较长、运行效率较低的语句。然后进行优化

1、启动和设置慢查询日志

mysql中慢查询日志默认是关闭的。能够通过配置文件my.ini或my.cnf中的log-slow-queries选项打开，也能够在mysql服务启动的时候使用--log--slow-queries[=file_name]启动慢查询日志。

启动慢查询日志时，须要在my.ini或者my.cnf文件里配置long_query_time选项指定记录阀值。假设某条查询语句的查询时间超过了这个值，这个查询过程将被记录到慢查询日志文件里。

在my.ini或者my.cnf文件里开启慢查询日志的配置例如以下：

[mysqld]

log-slow-queries[=path/[filename]]
long_query_time=n

path为日志文件所在文件夹路径，filename为日志文件名称。

假设不指定文件夹和文件名称称，默认存储在数据文件夹中文件名称为hostname-slow.log，hostname是mysqlserver的主机名。參数n是时间值，单位是秒。假设没有设置long-query_time选项，默认时间为10秒

开启慢查询日志

[mysqld]
log-slow-queries
long_query_time=1

2、查看慢查询日志

mysql的慢查询日志是以文本形式存储的，能够直接使用文本编辑器查看。在慢查询日志中，记录着运行时间较长的查询语句，用户能够从慢查询日志中获取运行效率较低的查询语句，为查询优化提供重要的根据

查看慢查询日志的一些參数

show variables like '%slow%';

查看慢查询日志文件中的内容，使用文本编辑器打开数据文件夹下的WIN7U-20130414Z-slow.log文件

E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld, Version: 5.5.19-log (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: (null)
Time                 Id Command    Argument
# Time: 140802  0:02:29
# User@Host: root[root] @ localhost [::1]
# Query_time: 7.578125  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
use test;
SET timestamp=1406908949;
SELECT BENCHMARK (10000000,PASSWORD ('newpwd'));

能够看到这里记录了一条慢查询日志。运行该条语句的帐户是root @ localhost 查询时间是Query_time: 7.578125秒查询语句是 SELECT BENCHMARK (10000000,PASSWORD ('newpwd'));
该语句查询时间大大超过了设置值1秒，因此被记录在慢查询日志文件里

BENCHMARK函数简单介绍：http://database.51cto.com/art/201010/229366.htm

3、删除慢查询日志

和通用查询日志一样。慢查询日志也能够直接删除。删除后在不重新启动server的情况下，须要运行

mysqladmin -u root -p flush logs

又一次生成日志文件。或者在client登录到server运行 flush logs; 语句重建日志文件官方mysql的慢查询日志在这里有一个缺陷。就是查询阀值仅仅能是1秒或以上，假设要设置一秒下面就无能为力了。这时候假设想找出1秒下面的慢查询SQL。能够使用percona提供的microslow-patch来突破限制，将慢查询时间阀值减小到毫秒级别

---

平时应打开哪些日志

日志既会影响mysql的性能，又会占用大量磁盘空间。

因此，假设不必要，应尽可能少地开启日志。

依据不同的使用环境。考虑开启不同的日志。比如开发环境中优化查询效率低的语句，能够开启慢查询日志。或者生产环境中发现某些SQL运行特别慢也能够开启假设磁盘空间不是特充足能够在高峰期间开启。在捕获到查询慢的SQL之后再关闭慢查询日志。假设须要搭建复制环境。那么就一定要开启二进制日志。假设数据特别重要也建议开启二进制日志，以便数据库损坏的时候也能够通过二进制日志，拯救一部分数据

通用日志不管在哪种情况下。一般不建议开启

---

总结

本文简单的阐述了MYSQL的日志面的内容。MYSQL的日志系统还是比較完好的，希望这篇文章对大家有帮助