MySQL技術內幕讀書筆記（三）——文件

時間 2019-11-06

標籤 mysql 技術內幕讀書筆記文件欄目 MySQL 简体版

原文原文鏈接

目錄mysql

文件

文件

有如下類型文件sql

參數文件：告訴MYSQL實例啓動時在哪裏找到數據庫文件，而且制定某些初始化參數。
日誌文件：用來記錄MYSQL實例對某種條件做出響應時寫入的文件。
socket文件：當用UNIX域套接字方式進行鏈接時須要的文件。
pid文件：MYSQL實例的進程ID文件
MySQL表結構文件：用來存放MYSQL表結構定義文件。
存儲引擎文件：

參數文件

查找參數文件命令數據庫

mysql --help | grep my.cnf

查找參數值命令緩存

SELECT * FROM GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'innodb_buffer%'\G;

# 推薦使用
SHOW VARIABLES LIKE 'innodb_buffer%'\G;

分爲兩類服務器

動態參數
靜態參數

動態參數能夠在MYSQL實例運行進行更改，靜態參數則是不可更改的。更改動態參數的語法以下：session

SET
| [global | session] system_var_name=expr
| [@@global. | @@session. | @@] system_var_name = expr

global：全局的，session：當前會話。說明參數的做用域是不通的。一些demo架構

# 改變當前會話，不會改變全局
SET read_buffer_size = 524288

# 改變全局會話參數，不會改變當前
SET @@global.read_buffer_size = 1048576;

# 查詢當前會話參數
SELECT @@session.read_buffer_size\G;

# 查詢全局會話參數
SELECT @@global.read_buffer_size\G;

可是這種修改，並不最終修改配置文件my.cnf的參數值，因此從新啓動後，參數仍是按照配置文件中的加載。併發

日誌文件

錯誤日誌

記錄了全部的錯誤信息、警告信息。查找錯誤日誌文件位置異步

SHOW VARIABLES LIKE 'log_error'\G;

慢查詢日誌

記錄查詢慢的SQL，能夠幫助優化。能夠設置記錄的閾值，而且打開開關socket

SHOW VARIABLES LIKE 'long_query_time'\G;
SHOW VARIABLES LIKE 'long_slow_queries'\G;

還有一個參數，若是SQL語句沒有使用索引，就會加入到慢查詢日誌文件（slow log)中。

SHOW VARIABLES LIKE 'log_queries_not_using_indeces'\G;

# 設置每分鐘容許記錄到slow log的且未使用因此的SQL語句次數，缺省爲0，表示沒有限制。
SHOW VARIABLES LIKE 'log_throttle_queries_not_using_indexs'

可是若是數據量比較大的話，很差分析分件的話，可使用MYSQL提供的mysqldumpslow命令

# 從指定文件讀取日誌
mysqldumpslow nh122-190-slow.log

# 獲得執行時間最長的10條SQL語句
mysqldumpslow -s al -n 10 david.log

還能夠通過配置，在slow_log中查詢慢日誌

# 慢日誌表名
SHOW CREATE TABLE mysql.show_log\G;

# 默認慢查詢輸出格式是FILE，則能夠設爲TABLE
SHOW VARIABLES LIKE 'log_output'\G;
SET GLOBAL log_output='TABLE';
SHOW VARIABLES LIKE 'log_output'\G;

# 查詢慢日誌
SELECT * FROM mysql.slow_log\G;

可是slow_log默認是用的CSV引擎，可以使用MyISAM引擎，提高查詢效率（大數據量）

ALTER TABLE mysql.slow_log ENGINE=MyISM;
SET GLOBAL slow_query_log=off;
ALTER TABLE mysql.slow_log ENGINE=MyISM;

經過額外的參數記錄相關信息到慢日誌表中

經過參數long_query_io將超過指定邏輯IO次數的SQL語句記錄到slow log中。默認值是100.

經過參數slow_query_type表示啓動slow log的方式

0：不將SQL記錄到slow log
1：根據運行時間將SQL語句記錄到slow log
2：根據邏輯IO次數將SQL語句記錄到slow log
3：根據運行時間以邏輯IO次數將SQL語句記錄到slow log

查詢日誌

記錄了全部對MYSQL數據庫請求的信息，名字通常爲主機名.log

二進制日誌(binary log)

記錄了對MYSQL數據庫執行更改的全部操做。只要操做使得數據庫發生變化，就會寫入二進制日誌。但操做若果未致使數據庫發生變化，也有可能寫入二進制日誌。例如

UPDATE t SET a = 1 WHERE a = 2;

SHOW MASTER STATUS\G;
show binlog events in 'mysqld.000008'\G;

二進制日誌主要做用

恢復：某些數據的恢復須要二進制文件。例如，在一個數據庫全被文件恢復後，用戶能夠經過二進制日誌進行point-in-time恢復
複製：經過複製和執行二進制日誌使一臺遠程的MYSQL數據庫(通常是slave或者standy)與一臺MYSQL數據庫(master或primary)進行實時同步。
審計：用戶能夠經過二進制日誌中的信息來進行審計，判斷是否有對數據庫進行注入的攻擊。

經過配置慘呼log-bin=[name]能夠啓動二進制日誌。若是不指定name，則默認二進制日誌文件名爲主機名，後綴名爲二進制日誌的序列號。

# 查詢二進制日誌路徑
show variablers like 'datadir';

# MYSQL調用LL
system ls -lh /user/local/mysql/data/;

bin_log.index爲二進制的索引文件，用來存儲過往產生的二進制日誌序號。

如下配置文件的參數影響着二進制日誌記錄的信息和行爲。

max_binlog_size：

指定單個二進制日誌文件的最大值。默認爲1G
binlog_cache_size：

當使用事務的表存儲引擎（INNODB）時，全部未提交的二進制日誌會被記錄到一個緩存中去，等待事務提交時直接將緩衝中的二進制日誌寫入二進制日誌文件，而緩衝的大小由binlog_cache_size決定，默認大小爲32K。

值過大，浪費空間；值過小，會把緩衝中的日誌寫入到一個臨時文件中。
```
# 查詢設置的緩存大小
SHOW VARIABLES LIKE 'binlog_cache_size';

# 查看緩衝池狀態
SHOW GLOBAL STATUS LIKE 'binlong_cache%';
```
sync_binlog：

默認狀況下，二進制日誌是使用緩衝寫的方式，可是數據庫宕機時，有可能缺乏一部分數據，給恢復和複製帶來問題，因此使用參數sync_binlog=[N]表示每寫緩衝多少次就同步到磁盤。若是N改爲1的話，就是同步寫磁盤來寫二進制日誌。可用性和IO性能須要進行取捨。

且當sync_binlog=1時，假設有事務還沒commit，也會將二進制日誌當即寫入磁盤，可是若是發生宕機，二進制日誌已經記錄了該事務信息，不能回滾。這個問題能夠經過將參數innodb_support_xa爲1來解決。
binlog-do-db：

表示須要寫入哪些庫的日誌
binlog-ignore-db：

表示須要忽略寫入哪些庫的日誌
log-slave-update：

若是須要搭建master->slave->slave架構的複製，須要設置log-slave-update參數。
binlog_format：

很是重要，影響記錄二進制日誌的格式。
- STATEMENT：記錄的是日誌的邏輯SQL語句。
  
  這個對於複製是有必定要求的，若是再主服務器運行rand、uuid等函數，又或者使用觸發器等操做，這些均可能會致使主從服務器上表中數據的不一致(not sync)。
  
  另外一個影響是：致使INNODB使用的默認事務隔離級別是REPEATABLE READ，若是使用READ COMMITTED的事務隔離界別，會出現相似丟失更新的現象，致使主從數據庫上的數據不一致。
- ROW：記錄表的行更改狀況
  
  相似於Oracle的物理Standby，修復了Statement格式下的複製問題，也能夠設置INNODB的事務隔離基本爲READ COMMITTED，以獲取更好的併發性。
- MIXED：默認採用STATEMENT格式進行二進制日誌文件的記錄，可是在一些狀況下會使用ROW格式。
  - 表的存儲引擎爲NDB
  - 使用了UUID()、USER()、CURRENT_USER()等不肯定函數。
  - 使用了INSERT DELAY語句
  - 使用了用戶定義函數(UDF)
  - 使用了臨時表(temporary table)
查看二進制日誌文件，只能使用MYSQL提供的工具mysqlbinlog

# 查看STATEMENT格式
mysqlbinlog --start-position=203 test.00004

# 查看ROW格式
mysqlbinlog -vv --start-position=203 test.00004

套接字文件

UNIX本地鏈接MYSQL能夠採用UNIX域套接字方式，這種方式須要個套接字文件

pid文件

MYSQL實例啓動時，會將本身的進程ID寫入一個文件中——該文件即爲pid文件。文件名由參數pid_file控制。

表結構定義文件

MYSQL數據的存儲是根據表進行的，每一個表都會有與之對應的文件。但不論表採用何種存儲引擎，MYSQL都有一個以frm爲後綴名的文件，這個文件記錄了該表的表結構定義。

也能夠用來存放視圖的定義。frm文件能夠直接查看。

INNODB存儲引擎文件

表空間文件

innoDB將存儲的數據按表空間進行存放。在默認配置下會有一個ibdatal文件，該文件就是默認的表空間文件。能夠經過參數innodb_data_file_path對其進行設置

innodb_data_file_path=datafile_spec1[;datafile_spec2]...

#demo 
#文件大小都設置爲2000MB，其次ibdata2文件使用完2000M以後能夠自動增加。
[mysqld]
innodb_data_file_path = /db/ibdatal:2000M;/dr2/db/ibdata2:2000M:autoextend

使用兩個文件組成表空間，若兩個文件位於不一樣的磁盤，能夠平均磁盤負載，提升數據的總體性能。設置以後全部數據都會存入共享表空間。若是設置參數innodb_filw_per_table就會給每一個表一個獨立的存儲空間。

SHOW VARIABLES LIKE 'innodb_file_per_table'\G;

注意，即便開啓了上述參數，獨立的表空間也只存儲對應表的數據、索引和插入緩衝BITMAP等信息。其餘信息仍是放在默認的表空間中。

重作日誌文件

默認狀況下，INNODB存儲引擎的數據目錄下會有兩個名爲ib_logfile0和ib_logfile1的文件。稱爲重作日誌文件，在恢復時相當重要。

每一個INNODB存儲引擎至少有一個重作日誌文件組，每一個文件組下至少有2個重作日誌文件。爲了更高的可靠性，用戶能夠設置多個的鏡像日誌組，將不一樣的文件組放在不一樣的磁盤上，提升重作日誌的可用性。

在日誌組中每一個重作日誌文件的大小一致，並以循環寫入的方式運行。

下列參數嚴重影響重作日誌文件的屬性。

innodb_log_file_size

指定每一個重作日誌文件的大小。

設置的過大，在恢復時可能須要不少的時間。設置的太小，一個事務須要屢次切換重作日誌文件。還可能致使頻繁的async checkpoint
innodb_log_files_in_group

指定日誌文件組中重作文件的數量。
innodb_mirrored_log_grooups

指定日誌鏡像文件組的數量，默認爲1.
innodb_log_group_home_dir

指定日誌文件組所在路徑。默認爲./，表示在數據庫的數據目錄下

SHOW VARIABLES LIKE 'innodb%log%'\G;

事務日誌和二進制日誌的區別：

二進制會記錄全部MYSQL數據庫有關的日誌記錄。包括各類引擎的日誌，而重作日誌只記錄有關該存儲引擎自己的事務日誌。
記錄的內容不一樣。二級制日誌文件記錄的是關於一個事務的具體操做，即該日誌的邏輯日誌。而INNODB存儲引擎的重作日誌文件記錄的是關於每一個頁的更改的物理狀況。
寫入的時間也不一樣，二進制日誌文件僅在事務提交前進行提交，即只寫磁盤一次，不論這時事務多大。而在事務進行的過程當中，卻不斷有重作日誌條目被寫入到重作日誌文件中。

INNODB存儲引擎中，對於各類不一樣的操做有着不一樣的重作日誌格式，可是基本格式相同。

1	2	3	4
reg_log_type	space	page_no	redo_log_body

由四個部分組成：

redo_log_type佔用1字節，表示重作日誌的類型。
space表示表空間的ID，但採用壓縮的方式，所以佔用的空間可能小於4字節。
page_on表示頁的偏移量，一樣採用壓縮的方式
redo_log_body表示每一個重作日誌的數據部分，恢復時須要調用響應的函數進行解析。

從重作日誌緩衝往磁盤寫入時，是按512字節（一個扇區）的大小進行寫入。因此保障寫入一定成功。不須要有doublewrite。

觸發緩衝寫入重作日誌的條件：

主線程每秒會將重作日誌寫入磁盤的重作日誌中，不論事務是否已經提交。
經過innodb_flush_log_at_trx_commit控制，表示在commit操做時，處理重作日誌的方式
- 0：表示事務提交時，並不將事務的重作日誌寫入磁盤上的日誌文件，而是等待主線程每秒的刷新
- 1：在執行commit時將重作日誌緩衝同步寫入磁盤
- 2：在執行commit時將重作日誌緩衝異步寫入磁盤，只保證這個動做會發生。

因此，爲了保障ACID中的持久性，通常就把這個參數設置爲1。