首页 > 代码库 > 我的MYSQL学习心得（十五） 日志
我的MYSQL学习心得（十五） 日志
我的MYSQL学习心得（十五） 日志
我的MYSQL学习心得（一） 简单语法
我的MYSQL学习心得（二） 数据类型宽度
我的MYSQL学习心得（三） 查看字段长度
我的MYSQL学习心得（四） 数据类型
我的MYSQL学习心得（五） 运算符
我的MYSQL学习心得（六） 函数
我的MYSQL学习心得（七） 查询
我的MYSQL学习心得（八） 插入 更新 删除
我的MYSQL学习心得（九） 索引
我的MYSQL学习心得（十） 自定义存储过程和函数
我的MYSQL学习心得（十一） 视图
我的MYSQL学习心得（十二） 触发器
我的MYSQL学习心得（十三） 权限管理
我的MYSQL学习心得（十四） 备份和恢复
我的MYSQL学习心得（十六） 优化
我的MYSQL学习心得（十七） 复制
这一篇《我的MYSQL学习心得（十五）》将会讲解MYSQL的日志
MYSQL里的日志主要分为4类，使用这些日志文件，可以查看MYSQL内部发生的事情。
分别是
1、错误日志：记录mysql服务的启动、运行、停止mysql服务时出现的问题
2、查询日志：记录建立的客户端连接和执行的语句
3、二进制日志：记录所有更改数据的语句，可以用于数据复制
4、慢查询日志：记录所有执行时间超过long_query_time的所有查询或不使用索引的查询
默认情况下，所有日志创建于mysql数据目录中。通过刷新日志，可以强制mysql关闭和重新打开日志文件（或者在某些情况下切换到
一个新的日志）。当执行一个FLUSH LOGS语句或执行mysqladmin flush-logs 或mysqladmin refresh 时，将刷新日志
如果使用mysql复制功能，在复制服务器上可以维护更多日志文件，这种日志称为接替日志
其他日志功能会降低mysql数据库的性能。例如，在查询非常频繁的mysql数据库系统中，如果开启了通用查询日志和慢查询日志，
mysql数据库会花费很多时间记录日志。同时，日志会占用大量的磁盘空间
二进制日志
二进制日志就是我们经常说的binlog，主要记录mysql数据库的变化。
二进制日志以一种有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。
二进制日志包含关于每个更新数据库的语句的执行时间信息。他不包含没有修改任何数据的语句，例如select语句
使用二进制日志的最大目的是最大可能地恢复数据库，因为二进制日志包含备份后进行的所有更新
1、启动和设置二进制日志
默认情况下，二进制日志是关闭的，可以通过修改mysql的配置文件来启动和设置二进制日志
my.ini中[mysqld]组下面有几个设置是关于二进制日志的：
log-bin[=PATH/[FILENAME]]expire_logs_days=10max_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-binexpire_logs_days=10max_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 ‘ioTZUw8BAAAAZwAAAGsAAAABAAQANS41LjIwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKhNlTEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==‘/*!*/;DELIMITER ;# End of log fileROLLBACK /* 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.000006Pos: 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、使用二进制日志还原数据库
如果mysql服务器启用了二进制日志，在数据库出现意外丢失数据时，可以使用mysqlbinlog工具从指定的时间点开始
（例如，最后一次备份）直到现在，或另外一个指定的时间点的日志中恢复数据
要想从二进制日志恢复数据，需要知道当前二进制日志文件的路径和文件名。一般可以从配置文件（即my.cnf或者my.ini，文件名取决于mysql
服务器的操作系统）中找到路径
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启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。
在MYSQL中，错误日志也是非常重要的，mysql将启动和停止数据库信息以及一些错误信息记录到错误日志中
1、启动和设置错误日志
在默认情况下，错误日志会记录到数据库的数据目录下。如果没有在配置文件中指定文件名，则文件名默认为hostname.err。
例如：mysql所在服务器主机名为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 disabled140705 16:41:17 InnoDB: Mutexes and rw_locks use Windows interlocked functions140705 16:41:17 InnoDB: Compressed tables use zlib 1.2.3140705 16:41:17 InnoDB: Initializing buffer pool, size = 2.0G140705 16:41:18 InnoDB: Completed initialization of buffer poolInnoDB: 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 MBInnoDB: Database physically writes the file full: wait...140705 16:41:18 InnoDB: Log file .\ib_logfile0 did not exist: new to be createdInnoDB: Setting log file .\ib_logfile0 size to 213 MBInnoDB: Database physically writes the file full: wait...InnoDB: Progress in MB: 100 200140705 16:41:21 InnoDB: Log file .\ib_logfile1 did not exist: new to be createdInnoDB: Setting log file .\ib_logfile1 size to 213 MBInnoDB: Database physically writes the file full: wait...InnoDB: Progress in MB: 100 200InnoDB: Doublewrite buffer not found: creating newInnoDB: Doublewrite buffer createdInnoDB: 127 rollback segment(s) active.InnoDB: Creating foreign key constraint system tablesInnoDB: Foreign key constraint system tables created140705 16:41:23 InnoDB: Waiting for the background threads to start140705 16:41:24 InnoDB: 1.1.8 started; log sequence number 0140705 16:41:24 [Note] Event Scheduler: Loaded 0 events140705 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 shutdown140705 23:44:14 [Note] Event Scheduler: Purging the queue. 0 events140705 23:44:14 InnoDB: Starting shutdown...140705 23:44:15 InnoDB: Shutdown completed; log sequence number 1595675140705 23:44:15 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140706 8:17:09 [Note] Plugin ‘FEDERATED‘ is disabled.140706 8:17:09 InnoDB: The InnoDB memory heap is disabled140706 8:17:09 InnoDB: Mutexes and rw_locks use Windows interlocked functions140706 8:17:09 InnoDB: Compressed tables use zlib 1.2.3140706 8:17:09 InnoDB: Initializing buffer pool, size = 2.0G140706 8:17:10 InnoDB: Completed initialization of buffer pool140706 8:17:10 InnoDB: highest supported file format is Barracuda.140706 8:17:14 InnoDB: Waiting for the background threads to start140706 8:17:15 InnoDB: 1.1.8 started; log sequence number 1595675140706 8:17:16 [Note] Event Scheduler: Loaded 0 events140706 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 shutdown140706 14:05:35 [Note] Event Scheduler: Purging the queue. 0 events140706 14:05:35 InnoDB: Starting shutdown...140706 14:05:36 InnoDB: Shutdown completed; log sequence number 1603322140706 14:05:37 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140718 21:47:03 [Note] Plugin ‘FEDERATED‘ is disabled.140718 21:47:03 InnoDB: The InnoDB memory heap is disabled140718 21:47:03 InnoDB: Mutexes and rw_locks use Windows interlocked functions140718 21:47:03 InnoDB: Compressed tables use zlib 1.2.3140718 21:47:03 InnoDB: Initializing buffer pool, size = 2.0G140718 21:47:03 InnoDB: Completed initialization of buffer pool140718 21:47:03 InnoDB: highest supported file format is Barracuda.140718 21:47:04 InnoDB: Waiting for the background threads to start140718 21:47:05 InnoDB: 1.1.8 started; log sequence number 1603322140718 21:47:06 [Note] Event Scheduler: Loaded 0 events140718 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 shutdown140719 20:02:45 [Note] Event Scheduler: Purging the queue. 0 events140719 20:02:46 InnoDB: Starting shutdown...140719 20:02:47 InnoDB: Shutdown completed; log sequence number 1603332140719 20:02:48 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140719 20:04:20 [Note] Plugin ‘FEDERATED‘ is disabled.140719 20:04:20 InnoDB: The InnoDB memory heap is disabled140719 20:04:20 InnoDB: Mutexes and rw_locks use Windows interlocked functions140719 20:04:20 InnoDB: Compressed tables use zlib 1.2.3140719 20:04:20 InnoDB: Initializing buffer pool, size = 2.0G140719 20:04:20 InnoDB: Completed initialization of buffer pool140719 20:04:20 InnoDB: highest supported file format is Barracuda.140719 20:04:21 InnoDB: Waiting for the background threads to start140719 20:04:22 InnoDB: 1.1.8 started; log sequence number 1603332140719 20:04:23 [Note] Event Scheduler: Loaded 0 events140719 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 shutdown140720 1:39:37 [Note] Event Scheduler: Purging the queue. 0 events140720 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 disabled140720 11:17:29 InnoDB: Mutexes and rw_locks use Windows interlocked functions140720 11:17:29 InnoDB: Compressed tables use zlib 1.2.3140720 11:17:29 InnoDB: Initializing buffer pool, size = 2.0G140720 11:17:29 InnoDB: Completed initialization of buffer pool140720 11:17:29 InnoDB: highest supported file format is Barracuda.140720 11:17:37 InnoDB: Waiting for the background threads to start140720 11:17:38 InnoDB: 1.1.8 started; log sequence number 1603332140720 11:17:39 [Note] Event Scheduler: Loaded 0 events140720 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 shutdown140720 13:40:21 [Note] Event Scheduler: Purging the queue. 0 events140720 13:40:22 InnoDB: Starting shutdown...140720 13:40:23 InnoDB: Shutdown completed; log sequence number 1603332140720 13:40:24 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140726 11:12:58 [Note] Plugin ‘FEDERATED‘ is disabled.140726 11:12:59 InnoDB: The InnoDB memory heap is disabled140726 11:12:59 InnoDB: Mutexes and rw_locks use Windows interlocked functions140726 11:12:59 InnoDB: Compressed tables use zlib 1.2.3140726 11:12:59 InnoDB: Initializing buffer pool, size = 2.0G140726 11:12:59 InnoDB: Completed initialization of buffer pool140726 11:12:59 InnoDB: highest supported file format is Barracuda.140726 11:13:06 InnoDB: Waiting for the background threads to start140726 11:13:07 InnoDB: 1.1.8 started; log sequence number 1603332140726 11:13:10 [Note] Event Scheduler: Loaded 0 events140726 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 shutdown140727 0:34:20 [Note] Event Scheduler: Purging the queue. 0 events140727 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 disabled140727 10:03:49 InnoDB: Mutexes and rw_locks use Windows interlocked functions140727 10:03:49 InnoDB: Compressed tables use zlib 1.2.3140727 10:03:49 InnoDB: Initializing buffer pool, size = 2.0G140727 10:03:49 InnoDB: Completed initialization of buffer pool140727 10:03:50 InnoDB: highest supported file format is Barracuda.140727 10:03:50 InnoDB: Waiting for the background threads to start140727 10:03:51 InnoDB: 1.1.8 started; log sequence number 1603332140727 10:03:52 [Note] Event Scheduler: Loaded 0 events140727 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 shutdown140727 14:29:56 [Note] Event Scheduler: Purging the queue. 0 events140727 14:29:58 InnoDB: Starting shutdown...140727 14:30:00 InnoDB: Shutdown completed; log sequence number 1643538140727 14:30:00 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140801 21:10:05 [Note] Plugin ‘FEDERATED‘ is disabled.140801 21:10:05 InnoDB: The InnoDB memory heap is disabled140801 21:10:05 InnoDB: Mutexes and rw_locks use Windows interlocked functions140801 21:10:05 InnoDB: Compressed tables use zlib 1.2.3140801 21:10:06 InnoDB: Initializing buffer pool, size = 2.0G140801 21:10:06 InnoDB: Completed initialization of buffer pool140801 21:10:06 InnoDB: highest supported file format is Barracuda.140801 21:10:09 InnoDB: Waiting for the background threads to start140801 21:10:10 InnoDB: 1.1.8 started; log sequence number 1643538140801 21:10:10 [Note] Event Scheduler: Loaded 0 events140801 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 shutdown140801 22:59:19 [Note] Event Scheduler: Purging the queue. 0 events140801 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 1643538140801 22:59:23 [Note] E:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete140801 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 disabled140801 22:59:24 InnoDB: Mutexes and rw_locks use Windows interlocked functions140801 22:59:24 InnoDB: Compressed tables use zlib 1.2.3140801 22:59:24 InnoDB: Initializing buffer pool, size = 2.0G140801 22:59:24 InnoDB: Completed initialization of buffer pool140801 22:59:24 InnoDB: highest supported file format is Barracuda.140801 22:59:24 InnoDB: Waiting for the background threads to start140801 22:59:25 InnoDB: 1.1.8 started; log sequence number 1643538140801 22:59:26 [Note] Event Scheduler: Loaded 0 events140801 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在重新加载日志的时候，如果文件不存在，
则会自动创建。所以在删除错误日志之后，如果需要重建日志文件需要在服务器端执行以下命令：
mysqladmin -u root -p flush-logs
或者在客户端登录mysql数据库，执行flush logs语句
flush logs;
删除err文件，并用flush logs语句重建log-error文件
手动删除文件
手动执行 flush logs; ，err文件恢复了
打开err文件，里面什么都没有
通用查询日志
通用查询日志记录了mysql的所有用户操作，包括启动和关闭服务、执行查询和更新语句等
1、启动和设置通用查询日志
mysql服务器默认情况下并没有开启通用查询日志。如果需要通用查询日志，可以通过修改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 Argument140801 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连接服务器与执行查询语句的记录
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是mysql服务器的主机名。参数n是时间值，单位是秒。
如果没有设置long-query_time选项，默认时间为10秒
开启慢查询日志
[mysqld]log-slow-querieslong_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: 0use 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、删除慢查询日志
和通用查询日志一样，慢查询日志也可以直接删除。删除后在不重启服务器的情况下，需要执行
mysqladmin -u root -p flush logs
重新生成日志文件，或者在客户端登录到服务器执行 flush logs; 语句重建日志文件
官方mysql的慢查询日志在这里有一个缺陷，就是查询阀值只能是1秒或以上，如果要设置一秒以下就无能为力了
这时候如果想找出1秒以下的慢查询SQL，可以使用percona提供的microslow-patch来突破限制，将慢查询时间阀值减小到毫秒级别
平时应打开哪些日志
日志既会影响mysql的性能，又会占用大量磁盘空间。因此，如果不必要，应尽可能少地开启日志。
根据不同的使用环境，考虑开启不同的日志。
例如开发环境中优化查询效率低的语句，可以开启慢查询日志，或者生产环境中发现某些SQL执行特别慢也可以开启
如果磁盘空间不是特充足可以在高峰期间开启，在捕获到查询慢的SQL之后再关闭慢查询日志
如果需要搭建复制环境，那么就一定要开启二进制日志，如果数据特别重要也建议开启二进制日志，以便数据库损坏的时候也可以通过二进制日志
挽救一部分数据
通用日志无论在哪种情况下，一般不建议开启
总结
本文简单的阐述了MYSQL的日志面的内容，MYSQL的日志系统还是比较完善的，希望这篇文章对大家有帮助
如有不对的地方，欢迎大家拍砖o(∩_∩)o