MySQL 架構組成--物理文件組成 for mysql6.7.13

http://hongge.blog.51cto.com/

1、MySQL Server 簡介

什麼是MySQL

MySQL 是由MySQL AB 公司（目前已經被SUN 公司收歸麾下）自主研發的，目前IT 行業

最流行的開放源代碼的數據庫管理系統之一，它同時也是一個支持多線程高併發多用戶的關

系型數據庫管理系統。

MySQL 數據庫以其簡單高效可靠的特色，在最近短短几年的時間就從一個名不見經傳的

數據庫系統，變成一個在IT 行業幾乎是無人不知的開源數據庫管理系統。從

小型的web 網站，至大型的企業級應用，處處均可見其身影的存在。

MySQL 與其餘數據庫的簡單比較

1）功能比較：

做爲一個成熟的數據庫管理系統，要知足各類各樣的商業需求，功能確定是重點參考對象的。MySQL通過多年的改進和完善以後，已經基本具有了全部通用數據庫管理系統所須要的相關功能。

MySQL 基本實現了ANSI SQL 92 的大部分標準，僅有少部分並不常常被使用的部分沒有

實現。好比在字段類型支持方面，另外一個著名的開源數據庫PostGreSQL 支持的類型是最完

整的，而Oracle 和其餘一些商業數據庫，好比DB二、Sybase 等，較MySQL 來講也要相對少一些。在事務支持方面，雖然MySQL 本身的存儲引擎並無提供，可是已經經過第三方插件式存儲引擎Innodb 實現了SQL 92 標準所定義的四個事務隔離級別的所有。

不過在可編程支持方面，MySQL 和其餘數據庫相比還有必定的差距，雖然最新版的MySQL

已經開始提供一些簡單的可編程支持，如開始支持Procedure，Function，Trigger 等，但

是所支持的功能還比較有限，和其餘幾大商用數據庫管理系統相比，還存在較大的不足。如

Oracle 有強大的PL/SQL，SQL Server 有T-SQL，PostGreSQL 也有功能很完善的PL/PGSQL

的支持。

總體來講， MySQL的功能徹底能夠知足咱們的通用商業需求，提供足夠強大的服務。並且無論是哪種數據庫在功能方面都不敢聲稱本身比其餘任何一款商用通用數據庫管理系統都強，甚至都不敢聲稱可以本身擁有某一數據庫產品的全部功能。由於每一款數據庫管理系統都有起自身的優點，也有起自身的限制，這隻能表明每一款產品所傾向的方向不同。

2）易用性比較：

從系統易用性方面來比較，每個使用過MySQL 的用戶都可以明顯地感受出MySQL 在這方面與其餘通用數據庫管理系統之間的優點所在。尤爲是相對於一些大型的商業數據庫管理系統如Oracle、DB2 以及Sybase 來講，對於普通用戶來講，操做的難易程度明顯不處於一

個級別。MySQL 一直都奉行簡單易用的原則，也正是靠這一特性，吸引了大量的初級數據庫用戶最終選擇了MySQL。

從安裝方面來講，MySQL 安裝包大小僅僅只有100MB 左右，這與幾大商業數據庫徹底不在一個數量級。安裝難易程度也要比Oracle 等商業數據庫簡單不少，不管是經過已經編譯好

的二進制分發包仍是源碼編譯安裝，都很是簡單。

再從數據庫建立來比較，MySQL 僅僅只須要一個簡單的CREATE DATABASE 命令，便可在瞬間完成建庫的動做，而Oracle 數據庫與之相比，建立一個數據庫簡直就是一個很是龐大的工程。固然，兩者數據庫的概念存在必定差異。

3）性能比較

性能方面，一直是MySQL 引覺得自豪的一個特色。在權威的第三方評測機構屢次測試較量各類數據庫TPCC 值的過程當中，MySQL 一直都有很是優異的表現，並且在其餘全部商用的通用數據庫管理系統中，僅僅只有Oracle 數據庫可以與其一較高下。

4）可靠性

關於可靠性的比較，MySQL 也有很是優異的表現，從當前最火的Facebook 這樣大型的網站都是使用MySQL 數據庫，就能夠看出，MySQL 在穩定可靠性方面，並且排在全球前10 位的大型網站裏面，大部分都有部分業務是運行在MySQL數據庫環境上，如Yahoo，Google 等。

總的來講，MySQL 數據庫在發展過程當中一直有本身的三個原則：簡單、高效、可靠。

MySQL 的主要適用場景

MySQL是目前最爲流行的開源數據庫管理系統軟件了。那麼MySQL 主要用於什麼場景下

1）Web 網站系統

Web 站點，是MySQL 最大的客戶羣，MySQL 之因此能成爲Web 站點開發者們最青睞的數據庫管理系統，是由於MySQL 數據庫的安裝配置都很是簡單，使用過程當中的維護也不像不少大型商業數據庫管理系統那麼複雜，並且性能出色。還有一個很是重要的緣由就是MySQL 是開放源代碼的，徹底能夠無償使用。

2）日誌記錄系統

MySQL 數據庫的插入和查詢性能都很是的高效，若是設計地較好，在使用MyISAM 存儲引擎的時候，二者能夠作到互不鎖定，達到很高的併發性能。因此，對須要大量的插入和查詢日誌記錄的系統來講，MySQL 是很是不錯的選擇。好比處理用戶的登陸日誌，操做日誌等是很是適合的應用場景。

3）數據倉庫系統

隨着如今數據倉庫數據量的飛速增加，咱們須要的存儲空間愈來愈大。數據量的不斷增加，使數據的統計分析變得愈來愈低效，也愈來愈困難。怎麼辦？這裏有幾個主要的解決思路，一個是採用昂貴的高性能主機以提升計算性能，用高端存儲設備提升I/O 性能，效果理想，可是成本很是高；第二個就是經過將數據複製到多臺使用大容量硬盤的廉價pc server上，以提升總體計算性能和I/O 能力，效果尚可，存儲空間有必定限制，成本低廉；第三個，經過將數據水平拆分，使用多臺廉價的pc server 和本地磁盤來存放數據，每臺機器上面都只有全部數據的一部分，解決了數據量的問題，全部pc server 一塊兒並行計算，也解決了計算能力問題，經過中間代理程序調配各臺機器的運算任務，既能夠解決計算性能問題又能夠解決I/O 性能問題，成本也很低廉。在上面的三個方案中，第二和第三個的實現，MySQL 都

有較大的優點。經過MySQL 的簡單複製功能，能夠很好的將數據從一臺主機複製到另一臺，

不只僅在局域網內能夠複製，在廣域網一樣能夠。固然，其餘的數據庫一樣也能夠作到，不是隻有MySQL 有這樣的功能。可是MySQL是免費的，其餘數據庫大多都是按照主機數量或者cpu 數量來收費，當咱們使用大量的pc server 的時候，license 費用至關驚人。第一個方案，基本上全部數據庫系統都可以實現，可是其高昂的成本並非每個公司都可以承擔的。

2、MySQL 架構組成

Mysql物理文件組成：

1）日誌文件：主要包含：錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進制日誌

日誌是mysql數據庫的重要組成部分。日誌文件中記錄着mysql數據庫運行期間發生的變化；也就是說用來記錄mysql數據庫的客戶端鏈接情況、SQL語句的執行狀況和錯誤信息等。當數據庫遭到意外的損壞時，能夠經過日誌查看文件出錯的緣由，而且能夠經過日誌文件進行數據恢復。

一、錯誤日誌：Error Log

在mysql數據庫中，錯誤日誌功能是默認開啓的。默認狀況下，錯誤日誌存儲在mysql數據庫的數據目錄中。錯誤日誌文件一般的名稱爲hostname.err。其中，hostname表示服務器主機名。

錯誤日誌信息能夠本身進行配置的，錯誤日誌所記錄的信息是能夠經過log-error和log-warnings來定義的，其中log-error是定義是否啓用錯誤日誌的功能和錯誤日誌的存儲位置，log-warnings是定義是否將警告信息也定義至錯誤日誌中。默認狀況下錯誤日誌大概記錄如下幾個方面的信息：服務器啓動和關閉過程當中的信息（未必是錯誤信息，如mysql如何啓動InnoDB的表空間文件的、如何初始化本身的存儲引擎的等等）、服務器運行過程當中的錯誤信息、事件調度器運行一個事件時產生的信息、在從服務器上啓動服務器進程時產生的信息

注1：MySQL有不少系統變量能夠設置，系統變量設置不一樣，會致使系統運行狀態的不一樣。所以mysql提供兩組命令，分別查看系統設置和運行狀態。
一、查看系統設置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where] 
SHOW VARIABLES： shows the values of MySQL system variables. 
二、運行狀態：
SHOW [GLOBAL | SESSION] STATUS [like_or_where] 
SHOW STATUS： provides server status information.

如何修改系統配置

方法1：配置文件設置my.cnf

如：binlog_cache_size = 1M

方法2：set global binlog_cache_size = 1048576;

注2：查看mysql的版本

或

或

通常而言，日誌級別的定義沒有會話變量都只是在全局級別下進行定義

錯誤日誌的狀態：

其中

log_error定義爲錯誤日誌文件路徑

log_error_verbosity:

The MySQL error log has received some attention in MySQL 5.7, with a new setting called log_error_verbosity.

There are three possible values, as documented in the manual:

Verbosity Value	Message Types Logged
1	Errors only
2	Errors and warnings
3	Errors, warnings, and notes (default)

更改錯誤日誌位置可使用log-error來設置形式以下

#vi /etc/my.cnf

log-error = /usr/local/mysql/data/mysqld.err

查看mysql錯誤日誌：

#tail /usr/local/mysql/data/mysqld.err

爲了方便維護須要，有時候會但願將錯誤日誌中的內容作備份並從新開始記錄，這時候

就能夠利用MySQL 的FLUSH LOGS 命令來告訴MySQL 備份舊日誌文件並生成新的日誌文件。備份文件名以「.old」結尾。

刪除錯誤日誌：

在mysql5.5.7以前：數據庫管理員能夠刪除很長時間以前的錯誤日誌，以保證mysql服務器上的硬盤空間。mysql數據庫中，可使用mysqladmin命令開啓新的錯誤日誌。mysqladmin命令的語法以下：mysqladmin –u root –p flush-logs也能夠登陸mysql數據庫中使用FLUSH LOGS語句來開啓新的錯誤日誌。

在mysql5.5.7以後：服務器將關閉此項功能。只能使用重命名原來的錯誤日誌文件，手動沖洗日誌建立一個新的：方式以下：

更多信息請查閱官方文檔：http://dev.mysql.com/doc/refman/5.5/en/error-log.html

http://dev.mysql.com/doc/refman/5.6/en/error-log.html

http://dev.mysql.com/doc/refman/5.7/en/error-log.html

二、二進制日誌：Binary Log & Binary Log Index

二進制日誌，也就是咱們常說的binlog，也是MySQL Server 中最爲重要的日誌之一，主要用於記錄修改數據或有可能引發數據改變的mysql語句，而且記錄了語句發生時間、執行時長、操做的數據等等。因此說經過二進制日誌能夠查詢mysql數據庫中進行了哪些變化。通常大小體積上限爲1G。

當咱們經過「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 的最大存儲上限，通常設置爲512M或1G,通常不能超過1G當日志達到該上限時，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 僅僅比較當前鏈接所處的數據庫（經過use db_name 切換後所在的數據庫）與參數設置的數據庫名，而不會分析query 語句所更新數據所在的數據庫。

mysql-bin.index 文件（binary log index）的功能是記錄全部Binary Log 的絕對路徑，保證MySQL 各類線程可以順利的根據它找到全部須要的Binary Log 文件。

binlog_cache_size =32768   #默認值32768 binlog_cache_size ：一個事務，在沒有提交（uncommitted）的時候，產生的日誌，記錄到Cache中；等到事務提交（committed）須要提交的時候，則把日誌持久化到磁盤。通常來講，若是咱們的數據庫中沒有什麼大事務，寫入也不是特別頻繁，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複製主要有三種方式：基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混合模式複製(mixed-based replication, MBR)。對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

① STATEMENT模式（SBR）

每一條會修改數據的sql語句會記錄到binlog中。優勢是並不須要記錄每一行的數據變化，減小了binlog日誌量，節約IO，提升性能。缺點是在某些狀況下會致使master-slave中的數據不一致(如sleep()函數， last_insert_id()，以及user-defined functions(udf)等會出現問題)

② ROW模式（RBR）

不記錄每條sql語句的信息，僅需記錄哪條數據被修改了，修改爲什麼樣了。缺點是會產生大量的日誌，讓日誌暴漲。

③ MIXED模式（MBR）

以上兩種模式的混合使用，通常的複製使用STATEMENT模式保存binlog，對於STATEMENT模式沒法複製的操做使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇日誌保存方式。即交替使用行和語句、由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日誌時。

經過編輯my.cnf中的log-bin選項能夠開啓二進制日誌；形式以下：

log-bin [=DIR/[filename]]

其中，DIR參數指定二進制文件的存儲路徑；filename參數指定二級制文件的文件名，其形式爲filename.number，number的形式爲00000一、000002等。每次重啓mysql服務或運行mysql> flush logs;都會生成一個新的二進制日誌文件，這些日誌文件的number會不斷地遞增。除了生成上述的文件外還會生成一個名爲filename.index的文件。這個文件中存儲全部二進制日誌文件的清單又稱爲二進制文件的索引

查看二進制日誌：

二進制日誌的定義方式爲二進制格式；使用此格式能夠存儲更多的信息，而且可使寫入二進制日誌的效率更高。可是不能直接使用查看命令打開並查看二進制日誌。

當前使用的二進制文件及所處位置

查看當前二進制文件的信息：

查看二進制日誌信息的命令：

語法格式：SHOW BINLOG EVENTS[IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

#查看全部的二進制信息

mysql> show binlog events\G;

#查看指定日誌的二進制信息

mysql> show binlog events in 'mysql-bin.000016'\G;

#從指定的事件位置開始

mysql> show binlog events  in 'mysql-bin.000016' from 727;

注：二進制日誌的記錄位置：一般爲上一個事件執行結束時間的位置

#指定偏移量(不是語句，是事件)

mysql> show binlog events in 'mysql-bin.000017' from 154 limit 3;

命令行下查看二進制日誌：

因爲沒法使用cat等方式直接打開並查看二進制日誌；因此必須使用mysqlbinlog命令。可是當正在執行mysql讀寫操做時建議不要使用此打開正在使用的二進制日誌文件；若非要打開可flush logs。mysqlbinlog命令的使用方式：

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 219 #事件開始處

#160829 0:23:22 server id 1 end_log_pos 296 CRC32 0xc81eb3b9 Query thread_id=2 exec_time=0 error_code=0

#160829 0:23:22年月日的簡寫方式；end_log_pos事件結束處；thread_id=2 哪一個會話線程建立的此語句；exec_time=0 執行時長單位爲秒；error_code=0 錯誤代碼0表示沒有

SET TIMESTAMP=1472401402/*!*/;

SET @@session.pseudo_thread_id=2/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C utf8 *//*!*/;

SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 296

#160829 0:23:22 server id 1 end_log_pos 393 CRC32 0xbc94b235 Query thread_id=2 exec_time=0 error_code=0

use `db2`/*!*/;

SET TIMESTAMP=1472401402/*!*/;

insert into tb1 values(3)

刪除二進制日誌信息：

二進制日誌會記錄大量的信息（其中包含一些無用的信息）。若是很長時間不清理二進制日誌，將會浪費不少的磁盤空間。可是，刪除以後可能致使數據庫崩潰時沒法進行恢復，因此若要刪除二進制日誌首先將其和數據庫備份一份，其中也只能刪除備份前的二進制日誌，新產生的日誌信息不可刪。也不可在關閉mysql服務器以後直接刪除由於這樣可能會給數據庫帶來錯誤的。若非要刪除二進制日誌須要作以下操做：導出備份數據庫和二進制日誌文件進行壓縮歸檔存儲。刪除二進制文件的方法以下：

方法1：根據文件或時間點來刪除二進制日誌：

語法形式：

mysql> PURGE { BINARY | MASTER } LOGS {TO 'log_name' | BEFORE datetime_expr }

其中TO 'log_name'表示把這個文件以前的其餘文件都刪除掉，也可以使用BEFORE datetime_expr指定把哪一個時間以前的二進制文件刪除了。

或者用ls查看

方法2：刪除全部的二進制日誌（慎用）：

使用RESET MASTER語句能夠刪除全部的二進制日誌。該語句的形式以下：

不建議在生產環境下使用此操做；刪除全部的二進制日誌後，Mysql將會從新建立新的二進制日誌。新二進制日誌的編號從000001開始。

三、事務日誌(或稱redo日誌)

事務日誌（InnoDB特有的日誌）能夠幫助提升事務的效率。使用事務日誌，存儲引擎在修改表的數據時只須要修改其內存拷貝，再把修改行爲記錄到持久在硬盤上的事務日誌中，而不用每次都將修改的數據自己持久到磁盤。事務日誌採用追加的方式，所以寫日誌的操做是磁盤上一小塊區域內的順序I/O，而不像隨機I/O須要在磁盤的多個地方移動磁頭，因此採用事務日誌的方式相對來講要快得多。事務日誌持久之後，內存中被修改的數據在後臺能夠慢慢的刷回到磁盤。目前大多數的存儲引擎都是這樣實現的。

若是數據的修改已經記錄到事務日誌並持久化，但數據自己尚未寫回磁盤，此時系統崩潰，存儲引擎在重啓時可以自動恢復這部分修改的數據。具備的恢復方式則視存儲引擎而定。

通常狀況下，mysql會默認提供多種存儲引擎,你能夠經過下面的查看:
查看你的mysql如今已提供什麼存儲引擎:
mysql> show engines;
看你的mysql當前默認的存儲引擎:
mysql> show variables like '%storage_engine%';
你要看某個表用了什麼引擎(在顯示結果裏參數engine後面的就表示該表當前用的存儲引擎):
mysql> show create table 表名;

注：

create table 庫名.表名 engine = innodb;
這樣就能夠將表的引擎變動爲innodb引擎了。
也能夠在建立表以後經過下面語句來變動：
alter table庫名.表名engine =innodb;

查看事務日誌的定義：

mysql> show global variables like '%log%';

顯示結果：

| innodb_flush_log_at_timeout | 1 |

| innodb_flush_log_at_trx_commit | 1 #在事務提交時innodb是否同步日誌從緩衝區到文件中，當這個值爲1（默認值）之時，在每一個事務提交時，日誌緩衝被寫到日誌文件，對日誌文件作到磁盤操做的刷新，性能會不好形成大量的磁盤I/O但這種方式最安全；若是設爲2,每次提交事務都會寫日誌，但並不會執行刷的操做。每秒定時會刷到日誌文件。要注意的是，並不能保證100%每秒必定都會刷到磁盤，這要取決於進程的調度。每次事務提交的時候將數據寫入事務日誌，而這裏的寫入僅是調用了文件系統的寫入操做，而文件系統是有 緩存的，因此這個寫入並不能保證數據已經寫入到物理磁盤。設置爲0，日誌緩衝每秒一次地被寫到日誌文件，而且對日誌文件作到磁盤操做的刷新，可是在一個事務提交不作任何操做。

注：刷寫的概念

刷寫實際上是兩個操做，刷（flush）和寫（write），區分這兩個概念是很重要的。在大多數的操做系統中，把Innodb的log buffer（內存）寫入日誌（調用系統調用write），只是簡單的把數據移到操做系統緩存中，操做系統緩存一樣指的是內存。並無實際的持久化數據。

因此，一般設爲0和2的時候，在崩潰或斷電的時候會丟失最後一秒的數據，由於這個時候數據只是存在於操做系統緩存。之因此說「一般」，可能會有丟失不僅1秒的數據的狀況，好比說執行flush操做的時候阻塞了。

總結

設爲1固然是最安全的，但性能頁是最差的（相對其餘兩個參數而言，但不是不能接受）。若是對數據一致性和完整性要求不高，徹底能夠設爲2,若是隻最求性能，例如高併發寫的日誌服務器，設爲0來得到更高性能

|

| innodb_locks_unsafe_for_binlog | OFF |

| innodb_log_buffer_size | 16777216 |

| innodb_log_checksums | ON |

| innodb_log_compressed_pages | ON |

| innodb_log_file_size | 50331648 #日誌文件大小 |

| innodb_log_files_in_group | 2 # DB中設置幾組事務日誌，默認是2 |

| innodb_log_group_home_dir | ./ #定義innodb事務日誌組的位置,此位置設置默認爲MySQL的datadir  |

每一個事務日誌都是大小爲50兆的文件（不一樣版本的mysql有差別）：

在mysql中默認以ib_logfile0,ib_logfile1名稱存在

四、慢查詢日誌：slow query log

顧名思義，慢查詢日誌中記錄的是執行時間較長的query，也就是咱們常說的slow query。

慢查詢日誌採用的是簡單的文本格式，能夠經過各類文本編輯器查看其中的內容。其中

記錄了語句執行的時刻，執行所消耗的時間，執行用戶，鏈接主機等相關信息。

慢查詢日誌的做用：

慢查詢日誌是用來記錄執行時間超過指定時間的查詢語句。經過慢查詢日誌，能夠查找出哪些查詢語句的執行效率很低，以便進行優化。通常建議開啓，它對服務器性能的影響微乎其微，可是能夠記錄mysql服務器上執行了很長時間的查詢語句。能夠幫助咱們定位性能問題的。MySQL 還提供了專門用來分析滿查詢日誌的工具程序mysqldumpslow，用來幫助數據庫管理人員解決可能存在的性能問題。

查看慢查詢日誌的定義：

啓動和設置慢查詢日誌：

方法1：經過配置文件my.cnf開啓慢查詢日誌：

注：在不一樣的mysql版本中，開啓慢查詢日誌參數不太同樣，不過均可以經過 show variables like "%slow%" 和show variables like "%long%"查看出來。

其中：

slow_query_log： off關閉狀態  on開啓狀態
slow_query_log_file  慢查詢日誌存放地點

long_query_time選項來設置一個時間值，時間以秒爲單位，能夠精確到微秒。若是查詢時間超過了這個時間值（默認爲10秒），這個查詢語句將被記錄到慢查詢日誌中, 設置爲0的話表示記錄全部的查詢。

slow_launch_time   表示若是創建線程花費了比這個值更長的時間,slow_launch_threads 計數器將增長

注：若是不指定存儲路徑，慢查詢日誌默認存儲到mysql數據庫的數據文件下，若是不指定文件名，默認文件名爲hostname-slow.log

修改my.cnf文件：

重啓mysqld服務

再次查詢慢查詢日誌定義：

方法2：經過登陸mysql服務器直接定義，方式以下：

mysql>set global slow_query_log=1;  #開啓慢查詢日誌

Query OK, 0 rowsaffected (0.35 sec)

mysql>set session long_query_time=0.0001; #更改時間（當前session中，退出則重置）

Query OK, 0 rowsaffected (0.00 sec)

mysql>set global long_query_time=0.0001; #更改時間（全局中，重啓服務則重置）

mysql> SHOW VARIABLES LIKE 'long%';  #查詢定義時間

查看慢查詢日誌

mysql> use mysql

mysql> selectuser,host from user where user="root";

或用系統查看文件內容命令如cat直接查看慢日誌文件

第一行表示記錄日誌時的時間。其格式是 YYYY-MM-DD HH:MM:SS。咱們能夠看出上面的查詢記錄於 2016 年 8 月 29 日下午 15:47：24 - 注意：這個是服務器時間.

MySql 用戶、服務器以及主機名第三行表示總的查詢時間、鎖定時間、"發送"或者返回的行數

Query_time: 0.000304 表示用了0.000304秒

Lock_time: 0.000128 表示鎖了0.000128秒

Rows_sent: 4 表示返回4行

Rows_examined: 4 表示一共查了4行

SET timestamp=UNIXTIME; 這是查詢實際發生的時間

何將其變成一個有用的時間，將 Unix 時間轉成一個可讀的時間，可使用 date –d@日誌中的時間戳

以看到查詢進行的同時記錄了該日誌 ，可是對於一臺超負載的服務器經常並不是如此。所以記住：SET timestamp= value 纔是實際的查詢的執行時間。

慢查詢分析mysqldumpslow

們能夠經過打開log文件查看得知哪些SQL執行效率低下。從日誌中，能夠發現查詢時間超過long_query_time時間的query爲慢查詢，而小於long_query_time時間的沒有出如今此日誌中。

若是慢查詢日誌中記錄內容不少，可使用mysqldumpslow工具（MySQL客戶端安裝自帶）來對慢查詢日誌進行分類彙總。mysqldumpslow對日誌文件進行了分類彙總，顯示彙總後摘要結果

進入log的存放目錄，運行

[root@localhost data]# mysqldumpslow mysqld-slow.log

注：

mysqldumpslow -s c -t 10 /database/mysql/slow-query.log                     

這會輸出記錄次數最多的10條SQL語句，其中：

-s, 是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒序；

-t, 是top n的意思，即爲返回前面多少條的數據；

-g, 後邊能夠寫一個正則匹配模式，大小寫不敏感的；

例如：

/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log                                

獲得返回記錄集最多的10個查詢。

/path/mysqldumpslow -s t -t 10 -g 「left join」 /database/mysql/slow-log      

獲得按照時間排序的前10條裏面含有左鏈接的查詢語句。

2）數據文據

在MySQL 中每個數據庫都會在定義好（或者默認）的數據目錄下存在一個以數據庫名字命名的文件夾，用來存放該數據庫中各類表數據文件。不一樣的MySQL 存儲引擎有各自不一樣的數據文件。如MyISAM 用「.MYD」做爲擴展名，Innodb 用「.ibd」，Archive 用「.arc」，CSV 用「.csv」，等等。

如何查看你的mysql如今已提供什麼存儲引擎:
mysql> show engines;
看你的mysql當前默認的存儲引擎:
mysql> show variables like '%storage_engine%';

你要看某個表用了什麼引擎(在顯示結果裏參數engine後面的就表示該表當前用的存儲引擎):
mysql> show create table 表名;

注：

create table 庫名.表名 engine = innodb; 這樣就能夠將表的引擎變動爲innodb引擎了。

登陸mysql，建立一個數據庫如testdb，並在數據庫中建立一個表，以下圖所示：

查看數據庫所在目錄會發現數據目錄下存在一個以數據庫名字命名的文件夾

查看testdb目錄的文件列表

從上圖能夠看出表使用的是innodb存儲引擎。

以myisam存儲引擎建立一個測試表tb2

查看數據庫目錄

注：修改mysql的默認存儲引擎

一、查看mysql存儲引擎命令，在mysql>提示符下搞入show engines;字段 Support爲:Default表示默認存儲引擎
二、設置InnoDB爲默認引擎：在配置文件my.cnf中的 [mysqld] 下面加入default-storage-engine=INNODB 一句
三、重啓mysql服務器：mysqladmin -u root -p shutdown或者service mysqld restart 登陸mysql數據庫，

一、「.frm」文件

與表相關的元數據（meta）信息都存放在「.frm」文件中，包括表結構的定義信息等。不管是什麼存儲引擎（MySQL經常使用的兩個存儲引擎是MyISAM和InnoDB），每個表都會有一個以表名命名的「.frm」文件。全部的「.frm」文件都存放在所屬數據庫的文件夾下面。

MyISAM數據庫表文件：.MYD文件：表數據文件；.MYI文件：索引文件

二、「.MYD」文件

「.MYD」文件是MyISAM 存儲引擎專用，存放MyISAM 表的數據。每個MyISAM 表都會有一個「.MYD」文件與之對應，一樣存放於所屬數據庫的文件夾下，和「.frm」文件在一塊兒。

三、「.MYI」文件

「.MYI」文件也是專屬於MyISAM 存儲引擎的，主要存放MyISAM 表的索引相關信息。對於MyISAM 存儲來講，能夠被cache 的內容主要就是來源於「.MYI」文件中。每個MyISAM

表對應一個「.MYI」文件，存放於位置和「.frm」以及「.MYD」同樣。

InnoDB採用表空間（tablespace）來管理數據，存儲表數據和索引。

.ibd文件：單表表空間文件，每一個表使用一個表空間文件（file per table），存放用戶數據庫表數據和索引。

InnoDB共享表空間（即InnoDB文件集，ib-file set）：ibdata一、ibdata2等，存儲InnoDB系統信息和用戶數據庫表數據和索引，全部表共用。

四、「.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_file_path 中能夠一次配置多個ibdata 文件。文件能夠是指定大小，也能夠是自動擴展的，可是Innodb 限制了僅僅只有最後一個ibdata 文件可以配置成自動擴展類型。當咱們須要添加新的ibdata 文件的時候，只能添加在innodb_data_file_path配置的最後，並且必須重啓MySQL 才能完成ibdata 的添加工做。不過若是咱們使用獨享表空間存儲方式的話，就不會有這樣的問題。

總結：

共享表空間以及獨佔表空間都是針對數據的存儲方式而言的。

共享表空間:  某一個數據庫的全部的表數據，索引文件所有放在一個文件中。

獨佔表空間:  每個表都將會生成以獨立的文件方式來進行存儲，每個表都有一個.frm表描述文件，還有一個.ibd文件。 其中這個文件包括了單獨一個表的數據內容以及索引內容。

二者之間的優缺點

共享表空間：
優勢：
能夠放表空間分紅多個文件存放到各個磁盤上。數據和文件放在一塊兒方便管理。
缺點：
全部的數據和索引存放到一個文件中，多個表及索引在表空間中混合存儲，這樣對於一個表作了大量刪除操做後表空間中將會有大量的空隙，特別是對於統計分析，日值系統這類應用最不適合用共享表空間。

獨立表空間：

優勢：
1．每一個表都有自已獨立的表空間。
2．每一個表的數據和索引都會存在自已的表空間中。
3．能夠實現單表在不一樣的數據庫中移動。
4．空間能夠回收
a)  Drop table操做自動回收表空間，若是對於統計分析或是日值表，刪除大量數據後能夠經過:alter table TableName engine=innodb;回縮不用的空間。
b)對於使用獨立表空間的表，無論怎麼刪除，表空間的碎片不會太嚴重的影響性能，並且還有機會處理。
缺點：
單表增長過大，如超過100個G。

相比較之下，使用獨佔表空間的效率以及性能會更高一點

查看當前數據庫的表空間管理類型

ON表明獨立表空間管理，OFF表明共享表空間管理；（查看單表的表空間管理方式，須要查看每一個表是否有單獨的數據文件）

Innodb共享表空間配置：

修改my.cnf文件：

參數解釋：

innodb_data_home_dir = "/path/" 數據庫文件所存放的目錄

innodb_log_group_home_dir = "/path/" 日誌存放目錄

innodb_data_file_path=ibdata1:10M:autoextend 設置一個可擴展大小的尺寸爲10MB的數據文件（共享數據文件），名爲ibdata1。沒有給出文件的位置，因此默認的是在MySQL的數據目錄內。

innodb_file_per_table=1｜0 //1爲使用獨佔表空間，0 爲使用共享表空間

注：InnoDB不建立目錄，因此在啓動服務器以前請確認」所配置的路徑目錄」的確存在。

重啓mysqld服務

mysqld啓動失敗,查看錯誤日誌

#tail -20 /usr/local/mysql/data/mysqld.err

顯示內容以下：

注：不一樣版本的mysql報錯略有不一樣，注意看錯誤日誌的內容。

從錯誤日誌中顯示能夠看出

在/etc/my.cnf文件中設置6400頁而當前ibdata1爲768頁

須要計算768/64=12
修改配置爲

重啓mysqld服務

啓動mysql，成功！

注：計算公式：64pages至關於1M，1page是16KB

若是不清楚默認文件page大小，能夠先 du -h ibdata1 查看下，再去設置；

這說明mysql5.7.13中ibdata初始化爲12M

登陸mysql執行mysql> show variables like '%innodb_file_per_table%';

這時新建的表就會使用共享表空間了。

建立一個數據庫testdb並新建一個表

向表中插入若干行數據

這裏定義一個存儲過程向表中插入100000行數據

調用存儲過程

查看錶中行數：

如何查看錶在表空間佔用狀況：

方法1：對INNODB，你能夠直接用命令show table status查看某個表的表空間佔用狀況。

方法2：

若是想知道MySQL數據庫中每一個表佔用的空間、表記錄的行數的話，能夠打開MySQL的 information_schema 數據庫。在該庫中有一個 TABLES 表，這個表主要字段分別是：

TABLE_SCHEMA : 數據庫名
TABLE_NAME：表名
ENGINE：所使用的存儲引擎
TABLE_ROWS：記錄數
DATA_LENGTH：數據大小
INDEX_LENGTH：索引大小

3、Replication相關文件：

1）master.info 文件：

master.info 文件存在於Slave 端的數據目錄下，裏面存放了該Slave 的Master 端的相關信息，包括Master 的主機地址，鏈接用戶，鏈接密碼，鏈接端口，當前日誌位置，已經讀取到的日誌位置等信息。

2）relay log 和relay log index

mysql-relay-bin.xxxxxn 文件用於存放Slave 端的I/O 線程從Master 端所讀取到的Binary Log 信息，而後由Slave 端的SQL 線程從該relay log 中讀取並解析相應的日誌信息，轉化成Master 所執行的SQL 語句，而後在Slave 端應用。

mysql-relay-bin.index 文件的功能相似於mysql-bin.index ，一樣是記錄日誌的存放位置的絕對路徑，只不過他所記錄的不是Binary Log，而是Relay Log。

3）relay-log.info 文件：

相似於master.info，它存放經過Slave 的I/O 線程寫入到本地的relay log 的相關信

息。供Slave 端的SQL 線程以及某些管理操做隨時可以獲取當前複製的相關信息。

4、其餘文件：

1）system config file

MySQL 的系統配置文件通常都是my.cnf，默認存放在"/etc"目錄下，my.cnf文件中包含多種參數選項組（group），每一種參數組都經過中括號給定了固定的組名，如「[mysqld]」組中包括了mysqld服務啓動時候的初始化參數，「[client]」組中包含着客戶端工具程序能夠讀取的參數。

2）pid file

pid file 是mysqld 應用程序在Unix/Linux 環境下的一個進程文件，和許多其餘

Unix/Linux 服務端程序同樣，存放着本身的進程id。

3）socket file

socket 文件也是在Unix/Linux 環境下才有的，用戶在Unix/Linux 環境下客戶端鏈接能夠不經過TCP/IP 網絡而直接使用Unix Socket 來鏈接MySQL。

mysql有兩種鏈接方式，經常使用的通常是tcp
mysql –h mysql主機ip -uroot -pxxx
mysql -S /path /mysql.sock

注：採用unix socket鏈接方式，比用tcp的方式更快，但只適用於mysql和應用同在一臺PC上。

http://hongge.blog.51cto.com/