錯誤日誌:Error Loghtml
(1)錯誤日誌記錄來mysql server在運行過程當中全部較爲嚴重的警告和錯誤信息。 (2)錯誤日誌還記錄了mysql server 每次啓動和關閉的詳細信息。 (3)默認狀況下,系統記錄錯誤日誌的功能是關閉的。錯誤信息被輸出到標準錯誤輸出(stderr)。 (4)若是想要開啓錯誤日誌記錄功能,須要在啓動時開啓-log-error選項。 (5)錯誤日誌的默認存放位置在數據目錄下,以hostname.err命名。 (6)可使用命令:--log-error[=file_name]修改其存放目錄和文件名 (7)爲了方便維護,有時候會但願將錯誤日誌中的內容作備份並從新開始記錄,這時候就可使用mysql的FLUSH LOGS 命令來告訴mysql備份舊日誌文件並生成新的日誌文件。備份文件名以 ".old"結尾。
二進制日誌:Binary Log & Binary Log Indexmysql
(1)二進制日誌,就是咱們常說的binlog,也是mysql server中最爲重要的日誌之一。 (2)經過「--log-bin[=file_name]」打開記錄功能 (3)mysql會將全部修改數據庫數據的query以二進制形式記錄到日誌文件中。 (4)固然,日誌中不只限與query語句這麼簡單,還包括了每一條query所執行的時間、所消耗的資源、以及相關的事務信息 (5)因此,binlog是事務安全的 (6)binlog記錄功能須要「--log-bin[=file_name]」參數的顯式指定才能開啓,若是爲指定file_name,則會在數據目錄下記錄爲mysql-bin.****。(**表明0~9之間的某一個數字,來表示該日誌的序號) (7)binlog還有一些其餘的附加選項參數: 【1】「--max_binlog_size「 《1》設置binlog最大的存儲上限,當日志達到該上限時,msql會從新建立一個日誌開始繼續記錄。 《2》不過偶爾也有超出該設置的binlog產生,通常都是由於在即將到達上限時,產生了一個較大的事務,爲了保證事務安全,mysql不會將同一個事務分開記錄到兩個binlog中。 【2】「--binlog-do-db=db_name」 《1》此參數明確告訴mysql,須要對某個(db_name)數據庫記錄binlog 《2》此參數明確指定了忽略針對其餘數據庫執行的query,而僅僅記錄指定的數據庫執行的query 【3】「--binlog-ignore-db=db_name」 《1》此參數明確指定了忽略針對某個數據庫執行的qurey 《2》當指定了某個數據庫的此參數後,mysql將記錄除了此數據庫以外的全部數據庫的binlog 【4】「--binlog-ignore-db=db_name」與「--binlog-do-db=db_name」兩個參數有一個共同的概念須要理解清楚: 《1》參數中的db_name不是指query語句更新的數據所在的數據庫,而是執行query語句的時候所處的鏈接的數據庫。 《2》例如:query語句更新數據庫B的數據,可是執行此query語句所在的數據庫是A,那麼binlog記錄的是數據庫A或者忽略數據庫A的相關query信息 (8)mysql-bin.index文件(binary log index)的功能是記錄全部binary log的絕對路經,保證mysql各類線程可以順利的根據它找到全部須要的binary log文件。
更新日誌:update logc++
(1)更新日誌是mysql在較老的版本使用的,其功能和binlog基本相似,只不過不是用二進制記錄而是用簡單的文本格式記錄內容。 (2)自從有了binlog後,就不多使用更新日誌了。 (3)從版本5.0開始,mysql已經不支持更新日誌了
查詢日誌:query log算法
(1)查詢日誌記錄mysql中全部query (2)「--log[=fina_name]」打開該功能 (3)因爲記錄了全部的query,包括全部的select,體積比較大,開啓後對性能影響較大,全部慎用該功能。 (4)通常只用於跟蹤某些特殊的sql性能問題纔會短暫打開該功能 (5)默認的查詢日誌文件名爲hostname.log
慢查詢日誌:slow query logsql
(1)顧名思義,慢查詢日誌中記錄的是執行時間較長的query,也就是咱們常說的slow query (2)經過設--log-slow-queries[=file_name]來打開該功能並設置記錄位置和文件名 (3)默認文件名是hostname-slow.log,默認目錄也是數據目錄。 (4)慢查詢日誌是簡單的文本格式,能夠經過各類文本編輯器查看內容。 (5)其中記錄來語句執行的時刻、執行所消耗的時間、執行用戶、鏈接主機等相關信息。 (6)mysql還提供了專門用來分析慢查詢日誌的工具程序mysqlslowdump,用來幫助數據庫管理人員解決可能存在的性能問題。
Innodb的在線redo日誌:innodb redo log數據庫
(1)Innodb是一個事務安全的存儲引擎,其事務安全性主要是經過在線redo日誌和記錄在表空間中的undo信息來保證的。 (2)redo日誌記錄了innodb所作的全部物理變動和事務信息 (3)經過redo日誌和undo信息,innodb保證了在任何狀況下的事務安全性。 (4)innodb的redo日誌默認存放在數據目錄下 (5)能夠經過innodb_log_group_home_dir來更改設置日誌的存放位置,經過innodb_log_files_in_group設置日誌的數量
「.frm」文件:windows
(1)與表相關的元數據(meta)信息都存放在「.frm」文件中 (2)包括表結構的定義信息等。 (3)不論表是什麼存儲引擎,每個表都會有一個以表名命名的「.frm」文件。 (4)全部的「.frm」文件都存放在所屬數據庫的文件夾下面。
「.MYD」文件:api
(1)「.MYD「文件是MyISAM存儲引擎專用,存放MyISAM表的數據。 (2)每個MyISAM表都會有一個「.MYD」文件與之對應,一樣存儲在所屬數據庫的文件夾下,和「.frm」文件在一塊兒。
「.MYI「文件:數組
(1)「.MYI「也是專屬與MyISAM存儲引擎的,主要存放MyISAM表的索引相關信息。 (2)對於MyISAM存儲來講,能夠被cache的內容主要就是來源於「.MYI」文件中。 (3)每個表對應一個「.MYI」文件,存放位置和「.frm」以及「.MYD」同樣。
「.idb「文件和ibdata文件::緩存
(1)這兩種文件都是存儲Innodb數據的文件 (2)之因此有兩種文件來存放Innodb數據(包括索引),是由於Innodb的數據存儲方式可以經過配置來決定是經過共享表空間存放數據,仍是獨享表空間存放存儲數據。 (3)「.idb」表明使用獨享表空間方式存儲數據,每一個表擁有一個「.idb」文件,文件存放在和MyISAM數據相同的位置。 (4)ibdata文件表明使用共享表空間的方式存儲數據,全部表共同使用一個(或者多個,可配置)ibdata文件 (5)ibdata文件能夠經過innodb_data_home_dir和innodb_data_file_path兩個參數共同配置組成。innodb_data_home_dir配置數據存放的總目錄,而innodb_data_file_path配置每個文件的名稱 (6)也能夠不配置innodb_data_home_dir,而直接使用絕對路經配置innodb_data_file_path參數完成配置。 (7)innodb_data_file_path能夠一次配置多個ibdata文件。文件是能夠指定大小,也能夠是自動擴展的,可是Innodb限制了僅僅只有最後一個ibdata文件可以配置成自動擴展類型。 (8)當咱們須要添加新的ibdata文件的時候,只能添加在innodb_data_file_path配置的最後,並且必須重啓mysql才能完成配置ibdata的添加工做。
master.info文件
(1)mysql的複製功能,相似主從複製,都會記錄maseter.info文件 (2)master.info存放於slave端的數據目錄下 (3)裏邊存放了該slave的master端的相關信息,包括master的主機地址、鏈接用戶、鏈接密碼、鏈接端口、當前日誌位置、已經讀取到的日誌位置等信息。
relay和relay log index
(1)mysql進行主主複製或主從複製的時候會在home目錄下面產生相應的relay log (2)relay log 不少方面都和binary log差很少。 (3)從服務器I/O 線程將主服務器的二進制日誌讀取過來記錄到從服務器本地文件中,而後sql線程會讀取relay-log日誌的內容並應用到從服務器,從而使從服務器和主服務器的數據保持一致。 (4)mysql-relay-bin.xxxxx 文件用於存放slave端的I/O 線程從master端讀取到的Binary Log信息 (5)而後由slave端的SQL線程從該relay log中讀取並解析相應的日誌信息,轉化成master所執行的sql語句,而後在slave端應用。 (6)mysql-relay-bin.index文件的功能相似於mysql-bin.index,一樣是記錄日誌的存放位置的絕對路經,只不過它所記錄的不是Binary Log,而是Relay Log。
relay-log.info文件
(1)相似與master.info,它用來存放經過slave的I/O 線程寫入到本地的relay log的相關信息。 (2)供slave端的sql線程以及某些管理操做隨時可以獲取當前複製的相關信息。
system config file
(1)mysql的系統配置文件通常是"my.cnf",unix/Linux下默認存放在/etc目錄下,windows環境通常存放在「c:/windows」目錄下面。 (2)「my.cnf」文件中包含多種參數選項組(group),每一種參數組都經過中括號給定了固定的組名。 (3)如「[mysqld]」組中包括了mysqld服務啓動時候的初始化參數,「[client]」組中包含着客戶端工具程序能夠讀取的參數,mysql程序使用的「[mysql]」,mysqlchk使用的「[mysqlchk]」等。 (4)若是讀者朋友本身編寫了某個客戶端程序,也能夠本身設定一個參數組名,將相關參數配置在裏面,而後調用mysql客戶端api程序中的參數讀取api讀取相關參數。
pid file
(1)pid file是mysqld應用程序在Unix/Linux環境下的一個進程文件,和許多其餘Unix/Linux服務端程序同樣,存放着本身的進程id。 (2)經過mysqld_safe啓動mysql的時候,mysqld_safe會檢查pid文件,若是pid文件不存在,不作處理;若是文件存在,且pid已佔用則報錯「A mysqld process already exists」;若是文件存在,但pid未佔用,則刪除pid文件。 (3)經過mysqld_safe啓動時,mysql pid file的做用是:在數據文件是同一份,但端口不一樣的狀況下,防止同一數據庫被啓動屢次
socket file
(1)socket文件也是在Unix/Linux 環境下才有的 (2)用戶在Unix/Linux 環境下客戶端鏈接,能夠不經過TCP/IP 網絡而直接使用Unix Socket來鏈接mysql (3)網絡上的兩個程序經過一個雙向的通訊鏈接實現數據的交換,這個鏈接的一端稱爲一個socket (4)通常在配置部署mysql環境時都會在mysql的my.cnf文件中[mysqld]組下添加上socket文件的路經,而這樣作的好處是:若是啓用了多實例mysql時,能夠經過socket文件來快速的登錄mysql對應不一樣端口下的實例
初始化模塊
(1)顧名思義,初始化模塊就是在mysql server啓動的時候,對整個系統作各類各樣的初始化操做。 (2)好比buffer、cache結構的初始化和內存空間的申請,各類系統變量的初始化設定,各類存儲引擎的初始化設置等。
核心API
(1)核心API模塊主要是爲了提供一些須要很是高效的底層操做功能的優化實現 (2)包括底層數據結構的實現,特殊算法的實現,字符串處理,小文件I/O ,格式化輸出,以及最重要的內存管理部分。 (3)核心API模塊的全部源代碼都集中在mysys和strings文件夾下
網絡交互模塊
(1)底層網絡交互模塊抽象出底層網絡交互所使用的接口api,實現底層網絡數據的接收和發送,以方便各個模塊調用,以及對這一部分的維護。 (2)全部源碼都在vio文件夾下面。
Client & Server交互協議模塊
(1)任何C/S結構的軟件系統,都確定會有本身獨有的信息交互協議,mysql也不例外。 (2)mysql的Client & Server 交互協議模塊,實現了客戶端與mysql交互的全部協議。 (3)固然這些協議都是創建在現有的OS和網絡協議之上,如TCP/IP 以及Unix Socket。
用戶模塊
(1)用戶模塊所實現的功能,主要包括用戶的登錄鏈接、權限控制和用戶的受權管理等。 (2)它就像myslq的大門守衛同樣,決定是否給來訪者「開門」。
訪問控制模塊
(1)造訪客人進門了就能夠想幹嗎就幹嗎嗎?爲了安全考慮,確定不能如此隨意。 (2)這時就須要訪問控制模塊實時監控客人的每個動做,給不一樣客人以不一樣的權限。 (3)訪問控制模塊實現的功能就是根據用戶模塊中各用戶的受權信息,以及數據庫自身特有的各類約束,來控制用戶對數據的訪問。 (4)用戶模塊和訪問控制模塊二者結合起來,組成了mysql整個數據庫系統的權限安全管理的功能。
鏈接管理、鏈接線程、線程管理
(1)鏈接管理模塊負責監聽mysql server接收的各類請求,接收鏈接請求,轉發全部鏈接請求到線程管理模塊。 (2)每個鏈接上mysql server 的客戶端請求都會被分配(或建立)一個鏈接線程爲其單獨服務。 (3)而鏈接線程的主要工做就是負責mysql server 與客戶端的通訊,接受客戶端的命令請求,傳遞server端的結果信息等。 (4)線程管理模塊則負責管理維護這些鏈接線程,包括線程的建立、線程的cache等。
query解析和轉發模塊
(1)在mysql中咱們習慣將全部client端發送給server端的命令都稱爲query (2)在mysql裏面,鏈接線程接收到客戶端的一個query後,會直接將該query傳遞給專門負責將各類query進行分類而後轉發給各個對應的處理模塊,這個模塊就是query解析和轉發模塊。 (3)其主要工做就是對query語句進行語義和語法的分析,而後按照不一樣的操做類型進行分類,而後做出針對性的轉發。
query cache模塊
(1)query cache模塊在mysql server中是一個很是重要的模塊。 (2)它的主要功能是將客戶端提交給mysql server的select類query請求的返回結果集cache到內存中,與該query的一個hash值作一個對應。 (3)該query所取數據的基表發生任何數據的變化以後,mysql會自動使該query的cache失效。 (4)在讀寫比例很是高的應用系統中,query cache對性能的提升是很是顯著的。固然它對內存的消耗也是很是大的。
query優化器模塊
(1)顧名思義,就是優化客戶端請求的query。 (2)根據客戶端請求的query語句,和數據庫中一些統計數據,在一系列算法的基礎上進行分析,得出一個最優的策略,告訴後面的程序如何取得這個query語句的結果。
表變動管理模塊
(1)表變動管理模塊主要是負責完成一些DML和DDL的query; (2)如:update、delete、insert、create table、alter table 等語句的處理。
表維護模塊
(1)表的狀態檢查、錯誤修復、以及優化和分析等工做都是表維護模塊須要作的事情。
系統狀態管理模塊
(1)系統狀態管理模塊負責在客戶端請求系統狀態的時候,將各類狀態返回給用戶; (2)像DBA經常使用的各類show status命令、show variables命令等,所獲得的結果都是由這個模塊返回的。
表管理器
(1)每個表都有一個表的定義文件,就是「.frm」文件 (2)表管理器的工做就是維護這些文件,以及一個cache,該cache中的主要內容是各個表的結構信息 (3)此外它還維護table級別的鎖管理。
日誌記錄模塊
(1)日誌記錄模塊主要負責整個系統級別的邏輯層的日誌的記錄; (2)包括error log、binary log、slow query log等
複製模塊
(1)複製模塊又分爲Master模塊和Salve模塊兩部分。 (2)Master模塊主要負責在Replication環境中讀取Master端的binary日誌,以及與Salve端的I/O 線程交互等工做。 (3)Salve模塊比Master模塊所要作的事情稍多一些,在系統中主要體如今兩個線程上面: 【1】一個是負責從Master接收binary日誌,並寫入本地relay log中的I/O 線程。 【2】另一個是負責從relay log中讀取相關日誌事件,而後解析成能夠在Slave端正確執行並獲得和Master端徹底相同的結果的命令再交給Slave執行的SQL線程。
存儲引擎接口模塊
(1)存儲引擎接口模塊能夠說是mysql最具備特點的一點了。 (2)目前各類數據庫產品中,基本只有mysql能夠實現其底層數據存儲引擎的插件式管理。 (3)這個模塊實際上只是一個抽象類,但正是由於它成功的將各類數據處理高度抽象化,才成就了今天mysql可插拔存儲引擎的特點。
mysql啓動初始化:
(1)當咱們執行啓動mysql命令以後,mysql 的初始化模塊就會從系統配置文件中讀取系統參數和命令行參數,並按照參數來初始化整個系統; (2)如申請並分配buffer、初始化全局變量、以及各類結構等。 (3)同時各個存儲引擎也被啓動,並進行各自的初始化工做。
當整個系統初始化結束後,由鏈接管理模塊接手:
(1)鏈接管理模塊會啓動處理客戶端鏈接請求的監聽程序; (2)包括TCP/IP的鏈接監聽,還有Unix的Socket監聽。 (3)這時候,mysql server就基本啓動完成,準備好接收客戶端請求了
當鏈接管理模塊監聽到客戶端的鏈接請求(藉助網絡交互模塊的相關功能),雙方經過Client & Server交互協議模塊所定義的協議「寒暄」幾句後
(1)鏈接管理模塊就會將鏈接請求轉發給線程管理模塊,去請求一個鏈接線程。 (2)線程管理模塊立刻又會將控制交給鏈接線程模塊,告訴鏈接線程模塊:如今我這邊有鏈接請求過來了,須要創建鏈接,你這邊處理下。 (3)鏈接線程模塊在接收到鏈接請求後,首先會檢查當前鏈接線程池中是否有被cache的空閒鏈接線程; (4)若是有,就取出一個和客戶端請求鏈接上,若是沒有空閒的鏈接線程,則創建一個新的鏈接線程與客戶端請求鏈接。 (5)固然,鏈接線程模塊並非在收到鏈接請求後立刻取出一個鏈接線程和客戶端請求鏈接,而是首先調用用戶模塊進行受權檢查,只有客戶端請求經過了受權檢查後,纔會將客戶端請求和負責請求的鏈接線程連上。
在mysql中,將客戶端請求分爲兩種類型:
(1)一種是query,須要調用Parser也就是Query解析和轉發模塊的解析纔可以執行的請求; (2)一種是command,不須要調用Parser就能夠直接執行的請求。
若是咱們的初始化配置中打開了Full Query Logging的功能:
(1)那麼Query解析與轉發模塊會調用日誌記錄模塊將請求計入日誌。 (2)無論是query類型的請求仍是一個command類型的請求,都會被記錄進入日誌,因此,出於性能考慮,通常不多打開Full Query Logging的功能。
當客戶端請求和鏈接線程「互通暗號(互通協議)」接上頭以後,鏈接線程就開始處理客戶端發送過來的各類命令(或query),接受相關請求。
(1)它將接收到的query語句轉給query解析和轉發模塊; (2)query解析器先對query進行基本的語義和語法解析; (3)而後根據命令類型不一樣,有些會直接處理,有些會分發給其餘模塊來處理。
若是一個query類型的請求,會將控制交給query解析器。
(1)query解析器首先會分析看是不是一個select類型的query; (2)若是是,則調用查詢緩存模塊,讓它檢查該query在query cache中是否存在 (3)若是有,則直接將cache中的數據返回給鏈接線程模塊,而後經過與客戶端的鏈接線程將數據傳輸給客戶端。 (4)若是不是一個能夠被cache的query類型,或者cache中沒有該query數據,那麼query將被繼續傳回query解析器,讓query解析器進行處理,再經過query分發器分發給相關處理模塊。 (5)若是解析器解析結果是一條未被cache的select語句,則將控制權交給Optimizer,也就是Query優化器模塊; (6)若是是DML或者是DDL語句,則會交給表變動管理模塊; (7)若是是一些更新統計信息、檢測、修復和整理類的query則會交給表維護模塊去處理; (8)複製相關的query則轉交給複製模塊去進行相應的處理; (9)請求狀態的query則轉交給了狀態收集報告模塊。 (10)實際上表變動管理模塊根據所對應的處理請求的不一樣,是分別由insert處理器、delete處理器、update處理器、create處理器,以及alter處理器這些小模塊來負責不一樣的DML和DDL的。
在各個模塊收到query解析和分發模塊分發過來的請求後:
(1)首先會經過訪問控制模塊檢查鏈接用戶是否有訪問目標表以及目標字段的權限, (2)若是有,就會調用表管理模塊請求相應的表,並獲取對應的鎖。 (3)表管理模塊首先會查看該表是否已經存在於table cache中, (4)若是已經打開,則直接進行鎖相關的處理,若是沒有在cache中,則須要再打開表文件獲取鎖,而後將打開的表交給表變動管理模塊。 (5)當表變動管理模塊獲取打開當表以後,就會根據該表的相關meta信息,判斷表的存儲引擎類型和其餘相關信息。 (6)根據表的存儲引擎信息,提交請求給存儲引擎接口模塊,調用對應的存儲引擎實現模塊,進行相應的處理。 (7)不過,對於表變動管理模塊來講,可見的僅是存儲引擎接口模塊所提供的一系列標準接口,底層存儲引擎實現模塊的具體實現,對於表變動管理模塊來講是透明的。 (8)它只須要調用對應的接口,並指明類型,接口模塊會根據表類型調用正確的存儲引擎來進行相應的處理
當一條query或者一個command處理完成(成功或失敗)以後,控制權都會交給鏈接線程模塊。
(1)若是處理成功,則將處理結果經過鏈接線程反饋給客戶端。 (2)若是處理過程當中發生錯誤,也會將相應的錯誤信息發送給客戶端,而後鏈接線程模塊會進行相應的清理工做,並繼續等待後面的請求,重複上面提到的過程,或者完成客戶端斷開鏈接的請求。
mysql:
(1)爲用戶提供一個命令行接口來操做管理mysql服務器 (2)基本的語法就不具體介紹了,你們能夠 運行一下「mysql --help」就會獲得相應的使用幫助信息
mysqladmin:
(1)顧名思義,提供的功能都是與mysql管理相關的各類功能 (2)如mysql server狀態檢查,各類統計信息的flush,建立/刪除數據庫,關閉mysql server等等 (3)mysqladmin所能作的事情,雖然大部分均可以經過mysql鏈接登錄上mysql server以後完成,可是大部分經過mysqladmin來完成操做會更加簡單方便。
mysqldump
(1)mysqldump功能就是將mysql server中的數據以sql語句的形式從數據庫中dump成文本文件 (2)雖然mysqldump是做爲mysql的一種邏輯備份工具爲你們所認識,但也能夠看做sql語句生成導出工具,由於經過mysqldump所生成的文件,全都是sql語句,包括數據庫和表的建立語句 (3)mysqldump所生成的sql文件能夠經過mysql工具執行 (4)經過參數「-d,--no-data」僅僅生成結構建立的語句
mysqllimport
(1)mysqlimport程序是一個將以特定格式存放的文本數據導入到指定的MySQL Server中的工具程序,好比將一個標準的csv文件導入到某指定數據庫的指定表中 (2)mysqlimport工具實際上也只是「load data infile」命令的一個包裝實現。
mysqlbinlog
(1)mysqlbinlog程序的主要功能就是分析MySQL Server所產生的二進制日誌(也就是你們所熟知的binlog)。 (2)當咱們但願經過以前備份的binlog作一些指定時間之類的恢復的時候,mysqlbinlog就能夠幫助咱們找到恢復操做須要作那些事情 (3)經過mysqlbinlog,咱們能夠解析出binlog中指定時間段或者指定日誌起始和結束位置的內容解析成SQL語句,並導出到指定的文件中, (4)在解析過程當中,還能夠經過指定數據庫名稱來過濾輸出內容。
mysqlcheck
(1)mysqlcheck工具程序能夠檢查(check),修復(repair),分析(analyze)和優化(optimize)MySQL Server中的表 (2)但並非全部的存儲引擎都支持這裏全部的四個功能,像Innodb就不支持修復功能。 (3)實際上,mysqlcheck程序的這四個功能均可以經過mysql鏈接登陸到MySQL Server以後來執行相應命令完成徹底相同的任務。
myisamchk
(1)功能有點相似「mysqlcheck -c/-r」,對檢查和修復MyISAM存儲引擎的表, (2)但只能對MyISAM存儲引擎的索引文件有效,並且不用登陸鏈接上MySQL Server便可完成操做。
myisampack
(1)對MyISAM表進行壓縮處理,以縮減佔用存儲空間, (2)通常主要用在歸檔備份的場景下, 並且壓縮後的MyISAM表會變成只讀,不能進行任何修改操做。 (3)當咱們但願歸檔備份某些歷史數據表,而又但願該表可以提供較爲高效的查詢服務的時候,就能夠經過myisampack工具程序來對該MyISAM表進行壓縮,由於即便雖然更換成archive存儲引擎也可以將表變成只讀的壓縮表,可是archive表是沒有索引支持的,而經過壓縮後的MyISAM表仍然可使用其索引。
mysqlhotcopy
(1)mysqlhotcopy和其餘的客戶端工具程序不太同樣的是他不是c(或者c++)程序編寫的,而是一個perl腳本程序 (2)僅能在Unix/Linux環境下使用。 (3)他的主要功能就是對MySQL 中的MyISAM存儲引擎的表進行在線備份操做, (4)其備份操做實際上就是經過對數據庫中的表進行加鎖,而後複製其結構,數據和索引文件來完成備份操做, (5)固然,也能夠經過指定「--noindices」告訴mysqlhotcopy不須要備份索引文件。
其餘工具
(1) 除了上面介紹的這些工具程序以外,MySQL還有自帶了其餘大量的工具程序, (2)如針對離線 Innodb 文件作 checksum 的 innochecksum, (3)轉換 mSQL C API 函數的 msql2mysql,dumpMyISAM全文索引的myisam_ftdump, (4)分析處理slowlog的sqldumpslow, (5)查詢mysql相關開發包位置和include文件位置的mysql_config, (6)向MySQL AB報告bug的mysqlbug, (7)測試套件mysqltest 和 mysql_client_test , (8)批量修改表存儲引擎類型的mysql_convert_table_format, (9)能從更新日誌中提取給定匹配規則的 query 語句的mysql_find_rows, (10)更改MyIsam存儲引擎表後綴名的mysql_fix_extensions, (11)修復系統表的mysql_fix_privilege_tables, (12)查看數據庫相關對象結構的mysqlshow, (13)MySQL升級工具 mysql_upgrade, (14)經過給定匹配模式來kill客戶端鏈接線程的mysql_zap, (15)查看錯誤號信息的perror,文本替換工具replace,等等一系列工具程序可供咱們使用。 (16)若是您但願在MySQL源代碼的基礎上作一些本身的修改,如修改MyISAM存儲引擎的時候,能夠利用myisamlog來進行跟蹤分析MyISAM的log。