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

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

一、MySQL Server 簡介

什麼是MySQL

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

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

系型數據庫管理系統。

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

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

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

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

1）功能比較：

作爲一個成熟的數據庫管理系統，要滿足各種各樣的商業需求，功能肯定是重點參考對象的。MySQL經過多年的改進和完善之後，已經基本具備了所有通用數據庫管理系統所需要的相關功能。

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

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

整的，而Oracle 和其他一些商業數據庫，比如DB2、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 費用相當驚人。第一個方案，基本上所有數據庫系統都能夠實現，但是其高昂的成本並不是每一個公司都能夠承擔的。

二、MySQL 架構組成

Mysql物理文件組成：

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

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

1、錯誤日誌：Error Log

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

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

注1：MySQL有很多系統變量可以設置，系統變量設置不同，會導致系統運行狀態的不同。因此mysql提供兩組命令，分別查看系統設置和運行狀態。
1、查看系統設置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where] 
SHOW VARIABLES： shows the values of MySQL system variables. 
2、運行狀態：
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

2、二進制日誌：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的形式爲000001、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開始。

3、事務日誌(或稱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名稱存在

4、慢查詢日誌：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的默認存儲引擎

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

1、“.frm”文件

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

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

2、“.MYD”文件

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

3、“.MYI”文件

“.MYI”文件也是專屬於MyISAM 存儲引擎的，主要存放MyISAM 表的索引相關信息。對於MyISAM 存儲來說，可以被cache 的內容主要就是來源於“.MYI”文件中。每一個MyISAM

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

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

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

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

4、“.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/