前言 麻雀雖小,五臟俱全。MySQL雖然以簡單著稱,但其內部結構並不簡單。
本章從MySQL物理組成、邏輯組成,以及相關工具幾個角度來介紹MySQL的總體架構組成,但願可以讓讀者對MySQL有一個更全面深刻的瞭解。
MySQL物理文件組成
日誌文件
一、錯誤日誌:ErrorLog 錯誤日誌記錄了MyQLServer運行過程當中全部較爲嚴重的警告和錯誤信息,以及MySQLServer每次啓動和關閉的詳細信息。
在默認狀況下,系統記錄錯誤日誌的功能是關閉的,錯誤信息被輸出到標準錯誤輸出(stderr),
若是要開啓系統記錄錯誤日誌的功能,須要在啓動時開啓-log-error選項。
錯誤日誌的默認存放位置在數據目錄下,以hostname.err命名。
可是可使用命令:--log-error[=file_name],修改其存放目錄和文件名。
爲了方便維護須要,有時候會但願將錯誤日誌中的內容作備份並從新開始記錄,
這時候就能夠利用MySQL的FLUSHLOGS命令來告訴MySQL備份舊日誌文件並生成新的日誌文件。備份文件名以「.old」結尾。
二、二進制日誌:BinaryLog&BinaryLogIndex 二進制日誌,也就是咱們常說的binlog,
也是MySQLServer中最爲重要的日誌之一。當咱們經過「--log-bin[=file_name]」打開了記錄的功能以後,
MySQL會將全部修改數據庫數據的query以二進制形式記錄到日誌文件中。固然,日誌中並不只限於query語句這麼簡單,還包括每一條query所執行的時間,所消耗的資源,以及相關的事務信息,因此binlog是事務安全的。 和錯誤日誌同樣,binlog記錄功能一樣須要
「--log-bin[=file_name]」參數的顯式指定才能開啓,若是未指定file_name,則會在數據目錄下記錄爲mysql-bin.******(*表明0~9之間的某一個數字,來表示該日誌的序號)。
binlog還有其餘一些附加選項參數: 「--max_binlog_size」設置binlog的最大存儲上限,當日志達到該上限時,MySQL會從新建立一個日誌開始繼續記錄。不過偶爾也有超出該設置的binlog產生,通常都是由於在即將達到上限時,產生了一個較大的事務,
爲了保證事務安全,MySQL不會將同一個事務分開記錄到兩個binlog中。
「--binlog-do-db=db_name」參數明確告訴MySQL,須要對某個(db_name)數據庫記錄binlog, 若是有了「--binlog-do-db=db_name」參數的顯式指定,MySQL會忽略針對其餘數據庫執行的query,而僅僅記錄針對指定數據庫執行的query。 「--binlog-ignore-db=db_name」與「--binlog-do-db=db_name」徹底相反,它顯式指定忽略某個(db_name)數據庫的binlog記錄,當指定了這個參數以後,MySQL會記錄指定數據庫之外全部的數據庫的binlog。
「--binlog-ignore-db=db_name」與「--binlog-do-db=db_name」兩個參數有一個共同的概念須要你們理解清楚, 參數中的db_name不是指query語句更新的數據所在的數據庫,而是執行query的時候當前所處的數據庫。不論更新哪一個數據庫的數據,MySQL僅僅比較當前鏈接所處的數據庫(經過usedb_name切換後所在的數據庫)與參數設置的數據庫名, 而不會分析query語句所更新數據所在的數據庫。
mysql-bin.index文件(binarylogindex)的功能是記錄全部BinaryLog的絕對路徑,保證MySQL各類線程可以順利的根據它找到全部須要的BinaryLog文件。
更新日誌:
updatelog 更新日誌是MySQL在較老的版本上使用的,其功能和binlog基本相似,只不過不是以二進制格式來記錄而是以簡單的文本格式記錄內容。
自從MySQL增長了binlog功能以後,就不多使用更新日誌了。
從版本5.0開始,MySQL已經再也不支持更新日誌了。
查詢日誌:querylog 查詢日誌記錄MySQL中全部的query,經過「--log[=fina_name]」來打開該功能。
因爲記錄了全部的query,包括全部的select,體積比較大,開啓後對性能也有較大的影響,因此請你們慎用該功能。
通常只用於跟蹤某些特殊的sql性能問題纔會短暫打開該功能。默認的查詢日誌文件名爲 hostname.log
慢查詢日誌:
slowquerylog 顧名思義,慢查詢日誌中記錄的是執行時間較長的query,也就是咱們常說的slowquery,
經過設--log-slow-queries[=file_name]來打開該功能並設置記錄位置和文件名,默認文件名爲hostname-slow.log,
默認目錄也是數據目錄。 慢查詢日誌採用的是簡單的文本格式,能夠經過各類文本編輯器查看其中的內容。
其中記錄了語句執行的時刻,執行所消耗的時間,執行用戶,鏈接主機等相關信息。
MySQL還提供了專門用來分析滿查詢日誌的工具程序mysqlslowdump,用來幫助數據庫管理人員解決可能存在的性能問題。
mysql> show global variables like '%slow%';
slow_query_log_file = /var/lib/mysql/slowsql.log
Innodb的在線redo日誌:
innodb redolog Innodb是一個事務安全的存儲引擎,其事務安全性主要就是經過在線redo日誌和記錄在表空間中的undo信息來保證的。
redo日誌中記錄了Innodb所作的全部物理變動和事務信息,
經過redo日誌和undo信息,Innodb保證了在任何狀況下的事務安全性。
Innodb的redo日誌一樣默認存放在數據目錄下,能夠經過
innodb_log_group_home_dir來更改設置日誌的存放位置,
經過innodb_log_files_in_group設置日誌的數量。
innodb_log_buffer_size = 2M
innodb_log_file_size = 32M
innodb_log_files_in_group = 3
數據文件
在MySQL中每個數據庫都會在定義好(或者默認)的數據目錄下存在一個以數據庫名字命名的文件夾,用來存放該數據庫中各類表數據文件。
不一樣的MySQL存儲引擎有各自不一樣的數據文件,存放位置也有區別。
多數存儲引擎的數據文件都存放在和MyISAM數據文件位置相同的目錄下,可是每一個數據文件的擴展名卻各不同。
如MyISAM用「.MYD」做爲擴展名,
Innodb用「.ibd」,
Archive用「.arc」,
CSV用「.csv」,
等等。
一、「.frm」文件 與表相關的元數據(meta)信息都存放在「.frm」文件中,包括表結構的定義信息等。不管是什麼存儲引擎,每個表都會有一個以表名命名的「.frm」文件。全部的「.frm」文件都存放在所屬數據庫的文件夾下面。
二、「.MYD」文件「 .MYD」文件是MyISAM存儲引擎專用,存放MyISAM表的數據。
每個MyISAM表都會有一個「.MYD」文件與之對應,一樣存放於所屬數據庫的文件夾下,和「.frm」文件在一塊兒。
三、「.MYI」文件 「.MYI」文件也是專屬於MyISAM存儲引擎的,主要存放MyISAM表的索引相關信息。對於MyISAM存儲來講,能夠被cache的內容主要就是來源於「.MYI」文件中。每個MyISAM表對應一個「.MYI」文件,存放於位置和「.frm」以及「.MYD」同樣。
四、「.ibd」文件和ibdata文件 這兩種文件都是存放Innodb數據的文件,之因此有兩種文件來存放Innodb的數據(包括索引),
是由於 Innodb 的數據存儲方式可以經過配置來決定是使用共享表空間存放存儲數據,仍是獨享表空間存放存儲數據。
*********獨享表空間存儲方式
####獨享表空間存儲方式使用「.ibd」文件來存放數據,且每一個表一個「.ibd」文件,文件存放在和MyISAM數據相同的位置。####
*********共享存儲表空間方式
若是選用共享存儲表空間來存放數據,則會使用 ibdata 文件來存放,全部表共同使用一個(或者多個,可自行配置)ibdata文件。
ibdata文件能夠經過 innodb_data_home_dir 和 innodb_data_file_path 兩個參數共同配置組成,
innodb_data_home_dir配置數據存放的總目錄,而innodb_data_file_path配置每個文件的名稱。
固然,也能夠不配置 innodb_data_home_dir 而直接在 innodb_data_file_path 參數配置的時候使用絕對路徑來完成配置。
innodb_data_file_path 中能夠一次配置多個 ibdata 文件。文件能夠是指定大小,也能夠是自動擴展的,
可是Innodb限制了僅僅只有最後一個ibdata文件可以配置成自動擴展類型。
當咱們須要添加新的ibdata文件的時候,只能添加在innodb_data_file_path配置的最後,並且必須重啓MySQL才能完成ibdata的添加工做。
不過若是咱們使用獨享表空間存儲方式的話,就不會有這樣的問題,
可是若是要使用裸設備的話,每一個表一個裸設備,可能形成裸設備數量很是大,
並且不太容易控制大小,實現比較困難,而共享表空間卻不會有這個問題,容易控制裸設備數量。
我我的仍是更傾向於使用獨享表空間存儲方式。固然,兩種方式各有利弊,看你們各自應用環境的側重點在那裏了。
上面僅僅介紹了兩種最經常使用存儲引擎的數據文件,此外其餘各類存儲引擎都有各自的數據文件,讀者朋友能夠自行建立某個存儲引擎的表作一個簡單的測試,作更多的瞭解。
Replication 複製 相關文件:
一、master.info文件: master.info 文件存在於 Slave(從機)端的數據目錄下,裏面存放了該Slave的Master端的相關信息,包括Master的主機地址,鏈接用戶,鏈接密碼,鏈接端口,當前日誌位置,已經讀取到的日誌位置等信息。
二、relaylog 和 relaylogindex
mysql-relay-bin.xxxxxn 文件用於存放Slave 端的 I/O 線程從Master端所讀取到的BinaryLog信息,
而後由Slave端的SQL線程從該relaylog中讀取並解析相應的日誌信息,轉化成Master所執行的SQL語句,而後在Slave端應用。
mysql-relay-bin.index文件的功能相似於mysql-bin.index,一樣是記錄日誌的存放位置的絕對路徑,只不過他所記錄的不是BinaryLog,而是RelayLog。
三、relay-log.info文件:
相似於master.info,它存放經過 Slave 的I/O線程寫入到本地的relaylog的相關信息。供Slave端的SQL線程以及某些管理操做隨時可以獲取當前複製的相關信息。
其餘文件:
一、system config file
MySQL的系統配置文件通常都是「my.cnf」,
Unix/Linux下默認存放在"/etc"目錄下,Windows環境通常存放在「c:/windows」目錄下面。
「my.cnf」文件中包含多種參數選項組(group),每一種參數組都經過中括號給定了固定的組名,
如「[mysqld]」組中包括了mysqld服務啓動時候的初始化參數,
「[client]」組中包含着客戶端工具程序能夠讀取的參數,此外還有其餘針對於各個客戶端軟件的特定參數組,如mysql程序使用的「[mysql]」,mysqlchk使用的「[mysqlchk]」,等等。
若是讀者朋友本身編寫了某個客戶端程序,也能夠本身設定一個參數組名,將相關參數配置在裏面,而後調用mysql客戶端api程序中的參數讀取api讀取相關參數。
二、pid file
pidfile是mysqld應用程序在Unix/Linux環境下的一個進程文件,和許多其餘Unix/Linux服務端程序同樣,存放着本身的進程id。
三、socket file
socket文件也是在Unix/Linux環境下才有的,用戶在Unix/Linux環境下客戶端鏈接能夠不經過TCP/IP網絡而直接使用Unix Socket來鏈接 MySQL。