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

本篇文章給大家主要講的是關于mysql數據庫的特性以及參數性能的內容，感興趣的話就一起來看看這篇文章吧，相信看完mysql數據庫的特性以及參數性能對大家多少有點參考價值吧。                

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

MySQL是一個關系型數據庫管理系統，開發者為瑞典MySQL AB公司，現在已經被Sun公司收購，支持FreeBSD、Linux、MAC、Windows等多種操作系統與其他的大型數據庫例如Oracle、DB2、SQL Server等相比功能稍弱一些

1、可以處理擁有上千萬條記錄的大型數據

2、支持常見的SQL語句規范

3、可移植行高，安裝簡單小巧

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

5、調試、管理，優化簡單(相對其他大型數據庫)

易用性比較

   從安裝方面來說，MySQL安裝包大小僅100MB左右，與那幾大商業數據庫相比完全不是一個數量級。它的安裝也比Oracle等商業數據庫容易很多，不論是通過已經編譯好的二進制分發包，還是通過源碼編譯安裝，都非常簡單。

性能比較

   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]”組中包含著客戶端工具程序可以讀取的參數。

2）pid file

pid file 是mysqld應用程序環境下的一個進程文件存放自己的pid號

3）socket file

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

mysql有兩種連接方式，常用的一般是tcp
mysql–hmysql主機ip -uroot -pxxx（可以遠程連接，但是速度稍慢）
mysql-S /path/mysql.sock （只能試用與本地連接，但速度快）

以上關于mysql數據庫的特性以及參數性能詳細內容，對大家有幫助嗎？如果想要了解更多相關，可以繼續關注我們的行業資訊板塊。