MySQL日誌查看詳解
解決問題：
了解MySQL日誌？
怎樣查看錯誤日誌？
怎樣查看慢日誌？
1. MySQL日誌分類？
MySQL日誌主要包含：錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進制日誌。
1.1 錯誤日誌：
在MySQL數據庫中，錯誤日誌功能是默認開啟的，而且無法被關閉。默認情況，錯誤日誌存儲在mysql數據庫的數據文件中。錯誤日誌文件通常的名稱為hostname.err（hostname表示服務器的主機名）。
錯誤日誌可以自己配置，錯誤日誌可以通過log-error和log-warnings來定義，其中log-error：配置是否啟用錯誤日誌功能和錯誤日誌的存儲位置？log-warning：配置是否將警告信息也定義至錯誤日誌中？
錯誤日誌記錄信息：服務器啟動關閉信息、運行錯誤信息、時間調度器運行一個事件時產生的信息、在服務器上啟動進程產生的信息。
1.2 查詢日誌：
默認情況，查詢日誌是關閉的。因為查詢日誌會記錄用戶所有的操作，其中還包括增刪改查等信息，如果在高並發的環境下會產生大量的信息，導致不必要的磁盤IO，會影響mysql的性能。
1.3 慢日誌：
慢查詢日誌是用來記錄執行時間超過指定時間的查詢語句。通過慢查詢日誌，可以查找出哪些查詢語句的執行效率很低，以便進行優化。一般建議開啟，它對服務器性能影響很小，但是可以記錄MySQL服務器上執行很長時間的查詢語句。可以幫助我們定義性能問題。
1.4 事務日誌：
事務日誌（InnoDB特有的日誌）可以幫助提高事務的效率。使用事務日誌，存儲引擎在修改表的數據時只需要修改其內存拷貝，再把改修改行為記錄到持久在硬盤上的事務日誌中，而不用每次都將修改的數據本身持久到磁盤。事務日誌采用追加的方式，因此寫日誌的操作是磁盤上一小塊區域內的順序I/O，而不像隨機I/O需要在磁盤的多個地方移動磁頭，所以采用事務日誌的方式相對來說要快得多。事務日誌持久以後，內存中被修改的數據在後臺可以慢慢的刷回到磁盤。目前大多數的存儲引擎都是這樣實現的，我們通常稱之為預寫式日誌，修改數據需要寫兩次磁盤。如果數據的修改已經記錄到事務日誌並持久化，但數據本身還沒有寫回磁盤，此時系統崩潰，存儲引擎在重啟時能夠自動恢復這部分修改的數據。具有的恢復方式則視存儲引擎而定。
1.5 二進制日誌：
二進制日誌也叫作變更日誌，主要用於記錄修改數據或有可能引起數據改變的mysql語句，並且記錄了語句發生時間、執行時長、操作的數據等等。所以說通過二進制日誌可以查詢mysql數據庫中進行了哪些變化。一般大小體積上限為1G。
2. 查看日誌信息？
mysql> show global variables like ‘%log%‘;
+-----------------------------------------+--------------------------------+
| Variable_name | Value |
+-----------------------------------------+--------------------------------+
| back_log | 250 |
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | STATEMENT |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| expire_logs_days | 0 |
| general_log | OFF |
| general_log_file | /var/lib/mysql/kafka2.log |
| innodb_api_enable_binlog | OFF |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 2 | ===>【事務日誌】詳解[1]
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 33554432 |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 536870912 |
| innodb_log_files_in_group | 2 | ===>【事務日誌】至少2個
| innodb_log_group_home_dir | ./ | ===>【事務日誌】定義innodb事務日誌組的文件目錄
| innodb_mirrored_log_groups | 1 | ===>【事務日誌】表示對日誌組做鏡像
| innodb_online_alter_log_max_size | 134217728 |
| innodb_undo_logs | 128 |
| log_bin | OFF |
| log_bin_basename | |
| log_bin_index | |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| log_error | ./kafka2.err | ===>【錯誤日誌】錯誤日誌輸出目錄以及錯誤日誌文件名
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| log_throttle_queries_not_using_indexes | 0 |
| log_warnings | 1 | ===>【錯誤日誌】是否把警告信息添加進錯誤日誌中
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| max_relay_log_size | 0 |
| relay_log | |
| relay_log_basename | |
| relay_log_index | |
| relay_log_info_file | relay-log.info |
| relay_log_info_repository | FILE |
| relay_log_purge | ON |
| relay_log_recovery | OFF |
| relay_log_space_limit | 0 |
| simplified_binlog_gtid_recovery | OFF |
| slow_query_log | OFF | ===>【慢日誌】查看慢日誌是否開啟
| slow_query_log_file | /var/lib/mysql/kafka2-slow.log | ===>【慢日誌】查看慢日誌的文件目錄以及文件名
| sql_log_bin | ON |
| sql_log_off | OFF |
| sync_binlog | 0 |
| sync_relay_log | 10000 |
| sync_relay_log_info | 10000 |
+-----------------------------------------+--------------------------------+
61 rows in set (0.00 sec)
2. 錯誤日誌？
2.2 配置
配置錯誤日誌：
vi /etc/my.cnf
[mysqld]
Log_error=DIR/[filename]
其中，DIR參數指定錯誤日誌的路徑，filename指定錯誤日誌的名稱。重啟服務器生效
4. 慢日誌？
4.2 啟動和設置慢查詢日誌
vi /etc/my.cnf [mysqld] slow_query_log=1 log-slow-queries [= DIR/[filename]]
其中，如果不指定存儲路徑，慢查詢日誌默認存儲到mysql數據庫的數據文件下，如果不指定文件名，默認文件名為hostname-slow.log。
4.3 查看時間默認超過多少為慢查詢日誌？
mysql> show global variables like ‘long%‘;
其中這個慢查詢時間並不是只表示語句自身執行超過10秒還包含由於其他資源被征用造成阻塞的查詢執行時間或其他原因等都被記錄到慢查詢中。所以這個慢查的時長表示從查詢開始到查詢結束中間包含可能的任何原因所經歷的所有時間。
修改：
vi /etc/my.cnf
[mysqld]
long_query_time=5
#long_query_time=0.005
5. 事務日誌
事務日誌(InnoDB特有的日誌)可以幫助提高事務的效率。
5.1 查看事務日誌
mysql> show global variables like ‘%log%‘;
innodb_flush_log_at_trx_commit:在事務提交時innodb是否同步日誌從緩沖到文件中1表示事務以提交就同步不提交每隔一秒同步一次，性能會很差造成大量的磁盤I/O；定義為2表示只有在事務提交時才會同步但是可能會丟失整個事務。
innodb_log_group_home_dir：定義innodb事務日誌組的位置。
innodb_mirrored_log_groups：表示對日誌組做鏡像。
6 二進制文件
二進制日誌也叫作變更日誌，主要用於記錄修改數據或有可能引起數據改變的mysql語句，並且記錄了語句發生時間、執行時長、操作的數據等等。所以說通過二進制日誌可以查詢mysql數據庫中進行了哪些變化。一般大小體積上限為1G。
6.1 查看
mysql> show global variables like "%log_bin%";
sql_log_bin ={ON|OFF} 用於控制會話級別二進制日誌功能的開啟或關閉。默認為ON，表示啟用記錄功能。用戶可以在會話級別修改此變量的值，但其必須具有SUPER權限。
binlog_cache_size =32768 #默認值32768 Binlog Cache用於在打開了二進制日誌（binlog）記錄功能的環境，是MySQL 用來提高binlog的記錄效率而設計的一個用於短時間內臨時緩存binlog數據的內存區域。一般來說，如果我們的數據庫中沒有什麽大事務，寫入也不是特別頻繁，2MB～4MB是一個合適的選擇。但是如果我們的數據庫大事務較多，寫入量比較大，可與適當調高binlog_cache_size。同時，我們可以通過binlog_cache_use 以及 binlog_cache_disk_use來分析設置的binlog_cache_size是否足夠，是否有大量的binlog_cache由於內存大小不夠而使用臨時文件（binlog_cache_disk_use）來緩存了。
binlog_stmt_cache_size= 32768 #當非事務語句使用二進制日誌緩存，但是超出binlog_stmt_cache_size時，使用一個臨時文件來存放這些語句。
log_bin = mysql-bin#指定binlog的位置，默認在數據目錄下。
binlog-format= {ROW|STATEMENT|MIXED} #指定二進制日誌的類型，默認為MIXED。如果設定了二進制日誌的格式，卻沒有啟用二進制日誌，則MySQL啟動時會產生警告日誌信息並記錄於錯誤日誌中。
sync_binlog = 10#設定多久同步一次二進制日誌至磁盤文件中，0表示不同步，任何正數值都表示對二進制每多少次寫操作之後同步一次。當autocommit的值為1時，每條語句的執行都會引起二進制日誌同步，否則，每個事務的提交會引起二進制日誌同步
max_binlog_cache_size= {4096 .. 18446744073709547520} #二進定日誌緩存空間大小，5.5.9及以後的版本僅應用於事務緩存，其上限由max_binlog_stmt_cache_size決定。
max_binlog_stmt_cache_size= {4096 .. 18446744073709547520} #二進定日誌緩存空間大小，5.5.9及以後的版本僅應用於事務緩存
expire_log_days ={0..99} #設定二進制日誌的過期天數，超出此天數的二進制日誌文件將被自動刪除。默認為0，表示不啟用過期自動刪除功能。如果啟用此功能，自動刪除工作通常發生在MySQL啟動時或FLUSH日誌時。
MySQL日誌查看詳解