mysql數據庫的參數以及性能的調配

時間 2019-11-06

原文原文鏈接

mysql數據庫的特性以及參數性能html

一：mysql與其餘數據庫的比較mysql

MySQL是一個關係型數據庫管理系統，開發者爲瑞典MySQL AB公司，如今已經被Sun公司收購，支持FreeBSD、Linux、MAC、Windows等多種操做系統與其餘的大型數據庫例如Oracle、DB二、SQL Server等相比功能稍弱一些sql

一、能夠處理擁有上千萬條記錄的大型數據數據庫

二、支持常見的SQL語句規範數組

三、可移植行高，安裝簡單小巧緩存

四、良好的運行效率，有豐富信息的網絡支持安全

五、調試、管理，優化簡單(相對其餘大型數據庫)服務器

易用性比較網絡

從安裝方面來講，MySQL安裝包大小僅100MB左右，與那幾大商業數據庫相比徹底不是一個數量級。它的安裝也比Oracle等商業數據庫容易不少，不管是經過已經編譯好的二進制分發包，仍是經過源碼編譯安裝，都很是簡單。session

性能比較

MySQL一直以來奉行一個原則，那就是在保證足夠穩定性的前提下，儘量地提升自身的處理能力。也就是說，在性能和功能方面，MySQL第一考慮的要素主要仍是性能，MySQL但願可以在知足客戶99%的需求的前提下，將剩餘的全部精力都用來努力提升系統性能，而不但願本身是一個比其餘任何數據庫的功能都要強大的產品。

整體來講，MySQL數據庫在發展過程當中一直追求三項原則：簡單、高效、可靠。

二：mysql架構組成

mysql物理文件組成：

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

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

首先挨個介紹日誌的功能：

錯誤日誌：Error Log

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

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

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.

那麼接下來修改系統配置：在主配置文件中

vi /etc/my.cnf

例如：log_bin=/usr/local/mysql/data/

查看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.

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

在主配置文件中： vi /etc/my.cnf

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

查看mysql的錯誤日誌內容：

在工做中有時候但願將錯誤日誌作備份，而且從新記錄，這時候可使用mysql的flush logs刷新日誌進行生成新的日誌文件。備份文件爲.beifen結尾

刪除錯誤日誌：

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

在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

二進制日誌，俗稱Binary Log，主要用於記錄修改數據或有可能引發數據改變的mysql語句；而且記錄語句的發生時間、執行時長、操做數據。。。。通常狀況下大小體積上限爲1G

當咱們經過「log-bin=file_name」打開了記錄的功能以後，MySQL 會將全部修改數據庫數據的query 以二進制形式記錄到日誌文件中。固然，日誌中並不只限於query 語句這麼簡單，還包括每一條query 所執行的時間，所消耗的資源，以及相關的事務信息，因此binlog是事務安全的。

主：若是log-bin日誌不開啓的話那麼將沒法作mysql主從複製

和錯誤日誌同樣，binlog記錄功能一樣須要「log-bin=file_name」參數的顯式指定才能開啓，若是未指定file_name，則會在數據目錄下記錄爲mysql-bin.******（*表明0～9 之間的某一個數字，來表示該日誌的序號）。

二進制的開啓：

當前是關閉狀態

能夠經過直配置文件開啓：

以後重啓mysql服務

再次查看mysql服務已經啓動：

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。

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_size ：一個事務，在沒有提交（uncommitted）的時候，產生的日誌，記錄到Cache中；等到事務提交（committed）須要提交的時候，則把日誌持久化到磁盤。

接着，binlog_cache_size設置多大呢？答案是：根據公司生產的實際狀況而定
設置太大的話，會比較消耗內存資源（Cache本質就是內存），更加須要注意的是：binlog_cache不是全局的，是按SESSION爲單位獨享分配的，也就是說當一個線程開始一個事務的時候，Mysql就會爲這個SESSION分配一個binlog_cache （備註：我想之因此以SESSION爲單位分配binlog_cache是有道理的，由於不一樣的mysql請求，產生的binlog數量不同的，批量插入數據必然產生大量的binlog，而簡單註冊一個用戶，產生的binlog有限，那麼JDBC鏈接上可否設置binlog_cache_size呢？）。
設置過小的話，若是用戶提交一個「長事務（long_transaction）」，好比：批量導入數據。那麼該事務必然會產生不少binlog，這樣cache可能不夠用（默認binlog_cache_size是32K），不夠用的時候mysql會把uncommitted的部分寫入臨時文件（臨時文件cache的效率必然沒有內存cache高），等到committed的時候纔會寫入正式的持久化日誌文件。

概念解釋：

事務表支持將批處理當作一個完整的任務統一提交或回滾，即對包含在事務中的多條語句要麼全執行，要麼所有不執行
非事務表則不支持此種操做，批處理中的語句若是遇到錯誤，在錯誤前的語句執行成功，以後的則不執行。

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服務器自行判斷。

其中基於行的定義格式數據量會大一些可是能夠保證數據的精確性

注：在生產環境下多使用MBR模式，雖然I/O使用增大，但對數據安全性比較高

sync_binlog = 10#設定多久同步一次二進制日誌至磁盤文件中，0表示不一樣步，任何正數值都表示對二進制每多少次寫操做以後同步一次。當autocommit的值爲1時，每條語句的執行都會引發二進制日誌同步，不然，每一個事務的提交會引發二進制日誌同步

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

log-bin = /usr路徑

其中，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 'log.000002' from 1215\G;

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

刪除二進制日誌信息：

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

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

語法形式：

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

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

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

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

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，也就是咱們常說的slowquery。

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

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

慢查詢日誌的做用：

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

查看慢查詢日誌的定義：

\啓動和設置慢查詢日誌：

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

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

其中：

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

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

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

修改my.cnf文件：

另外也能夠經過mysql直接定義（只不過屬於臨時生效）

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

Query OK, 0 rowsaffected (0.35 sec)

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

Query OK, 0 rowsaffected (0.00 sec)

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

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

查看慢查詢日誌

查看文件內容命令如cat直接查看慢日誌文件

數據文據 (在這裏主要介紹myisam和innodb的區別以及功能)

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

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

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

另外換能夠在建立表的時候在表名的後面跟engine=innodb 能夠改變表的引擎

create table 庫名.表名 engine = innodb

能夠在文件目錄當中查看建立的文件格式

查看mysql存儲引擎命令，在mysql>提示符下搞入show engines;字段 Support爲:Default表示默認存儲引擎

2、設置InnoDB爲默認引擎：在配置文件my.cnf中的 [mysqld] 下面加入default-storage-engine=INNODB 一句
3、重啓mysql服務器：service mysqld restart 登陸mysql數據庫，

1、「.frm」

主要存放表的數據；包括定義表結構信息，另外在每一個表當中都會有一個以表命名的.frm的文件，全部的文件存放在此文件夾下面

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

2、「.MYD」文件

myisam專門存放存儲引擎的專用文件

3、「.MYI」文件

「.MYI」文件也是專屬於MyISAM存儲引擎的，主要存放MyISAM表的索引相關信息。

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

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

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

.idb和ibdata的區別：

.id二者之間的優缺點

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

獨立表空間：

優勢：
1．每一個表都有自已獨立的表空間。
2．每一個表的數據和索引都會存在自已的表空間中。
3．能夠實現單表在不一樣的數據庫中移動。
4．空間能夠回收
b只能存放單獨的文件數據，ibdata能夠存放多的數據至關一個共享文件夾

查看當前的數據庫的表空間：

on表明獨立表空間；off表明共享表空間

那麼修改下主配置文件來開啓共享表空間

能夠先 du -h ibdata1 查看下

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

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

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

drop procedure if exists test； =====> 刪除以前存在的文件

create procedure test() ========> 建立test文件

begin ================>開始

declare i int；=========> 通告i的類型

set i=1 ======> i的數值等於1

while i < 100000 do =====> i的值若是小於100000

insert into lxf.ttt(id) values (i); =======>插入數據變量爲i

set i = i +1 ========> 每執行一次以後i的值加1直到爲99999

end while ======>循環結束

end &&結束

調用存儲過程：

查看標的行數

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

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 線程以及某些管理操做隨時可以獲取當前複製的相關信息。

其餘文件：

1）system config file

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