程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> 我的MYSQL學習心得(十五),mysql學習心得

我的MYSQL學習心得(十五),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=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、使用二進制日志還原數據庫

如果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 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) View Code

 

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    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連接服務器與執行查詢語句的記錄

 

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-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、刪除慢查詢日志

和通用查詢日志一樣,慢查詢日志也可以直接刪除。刪除後在不重啟服務器的情況下,需要執行

mysqladmin -u root -p flush logs

重新生成日志文件,或者在客戶端登錄到服務器執行 flush logs; 語句重建日志文件

 

官方mysql的慢查詢日志在這裡有一個缺陷,就是查詢閥值只能是1秒或以上,如果要設置一秒以下就無能為力了

這時候如果想找出1秒以下的慢查詢SQL,可以使用percona提供的microslow-patch來突破限制,將慢查詢時間閥值減小到毫秒級別


平時應打開哪些日志

日志既會影響mysql的性能,又會占用大量磁盤空間。因此,如果不必要,應盡可能少地開啟日志。

根據不同的使用環境,考慮開啟不同的日志。

例如開發環境中優化查詢效率低的語句,可以開啟慢查詢日志,或者生產環境中發現某些SQL執行特別慢也可以開啟

如果磁盤空間不是特充足可以在高峰期間開啟,在捕獲到查詢慢的SQL之後再關閉慢查詢日志

 

如果需要搭建復制環境,那麼就一定要開啟二進制日志,如果數據特別重要也建議開啟二進制日志,以便數據庫損壞的時候也可以通過二進制日志

挽救一部分數據

 

通用日志無論在哪種情況下,一般不建議開啟 


總結

本文簡單的闡述了MYSQL的日志面的內容,MYSQL的日志系統還是比較完善的,希望這篇文章對大家有幫助

 

如有不對的地方,歡迎大家拍磚o(∩_∩)o 


Java學習心得

先要聽老師講的,理解他的思路,然後試著寫老師講的代碼,不會的時候可一看看老師的代碼,關鍵是要知道代碼為什麼這樣寫,還要學會檢查異常,解決異常,這一點也很重要。

我覺得我學習那會,就是寫代碼,改錯。

代碼寫的多了,自然就知道該怎麼寫了。
純屬個人意見,希望對你有幫助。
 

初一的學習心得急救

有點多,你可以取其精華。
中學時代是人生的春天,是青少年長身體、長知識、形成人生觀的一個十分重要的時段.明確為什麼學習,怎樣學習,是每一個中學生認清和學會的問題.知識像海洋那樣遼闊,像海洋那樣浩瀚.一個人無論天資多高,精力多麼充沛,毅力多麼頑強,學習條件多麼優越,也不可能把所有知識學到手.有的同學總想學到一切,要薔薇也要雪.他們希望在一串串熟了的葡萄旁邊又開放著朵朵鮮花,可是,知識大海的守門老人告訴我們:這是不可能的呀!
知識時常需要更新,隨著時間的流逝,知識又可能遺忘,但獲取知識的方法卻不會被丟失.相傳有一個人,巧遇一仙翁,仙翁點石成金送給他,但他不要金子,而要仙翁點石成金的指頭.這個人為什麼要指頭呢?他懂得,不管送自己多少金子,金子總是有限的,但如果有了點石成金的指頭,那就可以隨心所欲了.古人說: "授之以魚,只供一飯之需,教人以漁,則終身受用無窮"也就是這個道理.毛澤東同志說過:"學習是學習,學習的學習也是學習,是更重要的學習".
學習方法是學習時采用的手段、方式和途徑.學法是在學習過程中產生和運用的.掌握良好的方法是很重要的事,但又不是一件容易的事情,這需要付出的艱苦努力,需要持之以恆的精神.只有每天堅持不懈,日久天長,學習才可能成為自覺的行為,從而掌握學習的主動權.,學習方法並不是什麼捷徑,它只是踏踏實實、刻苦學習的程序以及在這個學習過程中的各項具體措施.
國維有段為世人常常引用的名言:古今之成大事業大學問者,經過三種境界."昨夜西風雕碧樹,獨上高樓,望盡天涯路,此第一景也;衣帶漸寬終不悔,為伊消得人憔悴,此第二景也;眾裡尋他千百度,蓦然回首,那人卻在燈火闌珊處,此第三景也."第一景說的是要有信心,"獨上高樓",非信心不可;第二景說的是要有決心,"終不悔"實在是最大之決心了.第三景說的是要有恆心,"眾裡尋他千百度",沒有恆心,如何達得到?
古人說:"凡事預則立,不遇則廢."智力相同的兩個學生有無學習計劃,直接影響到學習效果.科學地利用時間,在有限的時間內有計劃地學習,這是科學學習方法的一條重要原則.學習缺乏計劃性是成績難以提高的主要原因之一.
要提高學習效率,變被動學習為主動學習,做學習的主人,應把握幾個步驟:
第一步就是抓好課前預習.
在預習過程中,邊看、邊想、邊寫,在書上適當勾畫和寫點批注.看完書後,最好能合上課本,獨立回憶一遍,及時檢查預習的效果,強化記憶.同時,可以初步理解教材的基本內容和思路,找出重點和不理解的問題,嘗試作筆記,把預習筆記作為課堂筆記的基礎.
我國古代軍事家孫子有一句名言:"知己知彼,百戰不殆."這是指對自己和自己的對手有了充分的了解之後,才可能有充分的准備,也才可能克敵制勝.預習就是 "知己知彼"的准備工作,就好像賽跑的槍聲.雖然賽跑規則中不允許搶跑,但是在學習中卻沒有這一規定,不但允許搶跑,鼓勵搶跑.做好預習學習,就是要搶在時間的前面,使學習由被動變為主動.
簡言之,預習就是上課前的自學,也就是在老師講課前,自己先獨立地學習新課內容,使自己對新課有初步理解和掌握的過程.預習抓得扎實,可以大大提高學習效率.
第二步是掌握聽講的正確方法.處理好聽講與作筆記的關系,重視課堂討論,不斷提高課堂學習效果.
學生上好課、聽好課,做好課前准備,包括心理上的准備、知識上的准備、物質上......余下全文>>
 

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved