面向讀者

該文適用于Linux CENTOS6.X及以上相干環(huán)境，mySQL版本為：5.x及以上。
本文讀者需要具有低級Linux系統(tǒng)使用的相干經(jīng)驗。
MYSQL的歷史
MySQL的爆發(fā)實際是在01、02年，特別是02年發(fā)布的4.0 Beta版，正式選定InnoDB作為默許引擎，對事務處理能力及數(shù)據(jù)緩存能力有了極大的提高。同年4.1版開始支持子查詢，至此MySQL終究演變成1個成熟的關(guān)系型數(shù)據(jù)庫系統(tǒng)。05年的5.0版本又添加了存儲進程、服務端游標、觸發(fā)器、查詢優(yōu)化和散布式事務功能，但同年被Oracle抄了后路，InnoDB被Oracle收編。08年，MySQL被Sun收購，09年，Oracle收購了Sun和MySQL。
MySQL最大的1個特點，就是自由選擇存儲引擎。每一個表都是1個文件，都可以選擇適合的存儲引擎。常見的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由于這類開放插件式的存儲引擎，比如要求數(shù)據(jù)庫與引擎之間的松耦合關(guān)系。從而致使文件的1致性大大下降。在SQL履行優(yōu)化方面，也就有著1些不可避免的瓶頸。在多表關(guān)聯(lián)、子查詢優(yōu)化、統(tǒng)計函數(shù)等方面是軟肋，而且只支持極簡單的HINT。

PostgreSQL官方宣稱的是：“The world’s most advanced open source database”。most advanced我不知道是怎樣定義的，由于PosgreSQL還是傳統(tǒng)B+樹索引的數(shù)據(jù)庫，在1些場景下，比如全插入場景，其還是會比其他1些數(shù)據(jù)庫要來得差很多，比如TokuDB，MongoDB。撇開這部份的因素，不能不承認PostgreSQL是最為強大的開源數(shù)據(jù)庫，也許，但是Oracle仍然才是最為強大的關(guān)系型數(shù)據(jù)庫。PostgreSQL陣營1直標榜自己在優(yōu)化器和Oracle可移植性方面的優(yōu)勢，我想這對照MySQL也許是成立的。但是，如果上述都成立的話，為何PostgreSQL在裝機量，流行度等指標上上遠遠地被后起之秀MySQL給超出了呢？全球前20大網(wǎng)站完全看不到PostgreSQL的身影呢？在寫本篇文章的時候，我倏地想到了1個類似的問題，業(yè)界公認手機質(zhì)量最好的Nokia，終究為何會倒下？

下圖是1個mySQL在大型網(wǎng)站和系統(tǒng)中的利用案例統(tǒng)計。

PostgreSQL另外一個痛點，我想很多人沒有會心識到的，就是在在線事務（OLTP）方面的性能問題。
PostgreSQL在功能方面也許是比較完全的，但是真的要進入到生產(chǎn)環(huán)節(jié)，看的不再是簡單的功能，由于大部份用戶都明白天常所使用的僅是數(shù)據(jù)庫提供的20%功能。MySQL 5.7現(xiàn)在已可以輕松到達50W QPS的性能，并支持通過NoSQL接口可以到達100W QPS，這是PostgreSQL為何沒有能在互聯(lián)網(wǎng)時期站住腳根的1個重要緣由之1。在線事務對性能的要求之刻薄，是普通用戶所沒法感知的。
PostgreSQL最大的優(yōu)勢是在線分析的場景，由于其優(yōu)化器對Join的支持可謂全面，對復雜查詢有著良好的支持，從Oracle遷移到PostgreSQL的本錢會比較低。基于PostgreSQL的GreenPlum也已開源，因此PostgreSQL目前在這方便是較為領(lǐng)先的。

MYSQL

MySQL數(shù)據(jù)庫官方的口號是：“ The world’s most popular open source database.”。對照PostgreSQL，這句話簡直沒法攻擊，并且MySQL官方的目標也1直是成為最為流行的數(shù)據(jù)庫。通過互聯(lián)網(wǎng)浪潮，移動互聯(lián)的時期，MySQL是真的做到了。
MySQL的優(yōu)勢是開源與開放性架構(gòu)，使其具有有著各種分支版本與存儲引擎可供選擇。除官方的InnoDB存儲引擎，還有TokuDB，Infobright引擎可在特定場合下進行使用。也正是由于MySQL的開源與開放，使得大量的開發(fā)人員加入到了MySQL的圍繞。MySQL是1個非常成功的開源項目，可能很多人疏忽了這個重要的因素。
MySQL被Oracle收購后表現(xiàn)的愈來愈好，1方面是功能愈來愈與Oracle數(shù)據(jù)庫接近，很多時候給我的感覺就是開源的Oracle數(shù)據(jù)庫，另外一個重要的改進就是bug愈來愈少，乃至很多遺留了有近10年的bug也已逐一修復。官方這樣嚴謹?shù)膽B(tài)度，使得MySQL逐步站穩(wěn)了并開始蠶食1部份的企業(yè)市場，世界500強的選擇就是最好的證明。

下圖是1個mySQL在大型網(wǎng)站和系統(tǒng)中的利用案例統(tǒng)計。

MySQL在性能與流行度上的優(yōu)勢我不想再做過量的筆墨，由于這是任何人都沒法躲避的事實。MySQL數(shù)據(jù)庫之前被PostgreSQL陣營攻擊就是優(yōu)化器，對多表JOIN的性能和不支持Hash Join。但是，很多人沒成心識到，MySQL已在5.6版本支持了MRR（Multi-Range Read），ICP（Index Condition Pushdown），BKA（Batched Key Access ）Join這些優(yōu)化，多表的JOIN性能已得到了很大幅度的提升。不能否則，MySQL仍然不支持Hash Join，但是這些優(yōu)化的引入已使得MySQL的Join性能提升到了1個新臺階。同時，在在線分析的領(lǐng)域，用戶真的不關(guān)心使用Hash Join可以5分鐘出報表，而是用MySQL需要8分鐘，這些時間完全是可以容忍的。然在在線事務領(lǐng)域，0.1的時間都是所不能容忍的。因此，本人在這里呼吁，嘗試升級MySQL到5.6，5.7版本，而不要仍然停留在5.1或5.5版本。
MySQL替換Oracle另外一個被詬病的就是沒有Oracle的透明網(wǎng)關(guān)(Transparent Gateway)功能，MySQL自帶的Fedorate存儲引擎支持MySQL數(shù)據(jù)庫間的查詢，不支持異構(gòu)數(shù)據(jù)庫之前的查詢。但是，這個問題已給MariaDB解決，用戶只需要通過Connect存儲引擎，就可以到達類似Oracle透明網(wǎng)關(guān)的功能。
另外，還有用戶提出MySQL不支持分區(qū)的全局索引，物化視圖等，其實這些都可以通過變通的方法實現(xiàn)，如：Amoeba原蟲或是最早進的mycat，這些技術(shù)也在網(wǎng)易、淘寶這樣的互聯(lián)網(wǎng)公司使用。
即便官方的MySQL沒法滿足你的需求，但是用戶仍然有InfoBright與TokuDB存儲引擎的選擇。InfoBright是列存的數(shù)據(jù)庫引擎，非常適用于在線分析領(lǐng)域，這點連PostgreSQL都沒法進行匹敵。TokuDB是1種類似LSM數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)引擎，在大并發(fā)的插入生產(chǎn)環(huán)境下，其對照各種傳統(tǒng)數(shù)據(jù)庫都有著顯著的優(yōu)勢，即便對照PostgreSQL與Oracle數(shù)據(jù)庫本身。總之，MySQL能夠在各種維度滿足用戶對數(shù)據(jù)庫的各種需求。
PosgreSQL與MySQL對照，最為關(guān)鍵的是全部人材的儲備。看看中國的互聯(lián)網(wǎng)公司基本都已將MySQL數(shù)據(jù)庫作為標配，而PostgreSQL乃至連備胎都沒法入選。MySQL在互聯(lián)網(wǎng)行業(yè)積累了大量的高可用架構(gòu)，散布式架構(gòu)與災備經(jīng)驗，但是PostgreSQL幾近為0。再看看圖書市場，PostgreSQL鳳毛菱角，而MySQL則有很好的書籍供DBA，開發(fā)人員，架構(gòu)師等學習。然即便如此，MySQL離Oracle數(shù)據(jù)庫本身的積累還有很長的路要走。

去IOE最早是由淘寶提出，旨在去除IT架構(gòu)中的IBM小型機，Oracle數(shù)據(jù)庫，EMC存儲。去IE是比較簡單的事情，由于這僅是硬件的替換。另外，X86技術(shù)也愈來愈成熟，穩(wěn)定性與小機的差距不斷縮小。但是去Oracle數(shù)據(jù)庫才是淘寶去IOE的難點與精華所在。全部去Oracle用時3，4年的時間。其中伴隨著功能內(nèi)部工程師的質(zhì)疑，大量Oracle人材的流失，但終究已證明了MySQL數(shù)據(jù)庫替換Oracle的可行性。
筆者高興的是傳統(tǒng)企業(yè)也開始有這樣的“覺悟”開始逐漸進行去IOE的嘗試，不管這類嘗試是主動還是被動，但都是值得尊重的行動。緣由在于去Oracle數(shù)據(jù)庫這件事情其實不那末簡單。數(shù)據(jù)庫是傳統(tǒng)企業(yè)最為核心的資產(chǎn)，任何損失都是不可接受的。而去年銀監(jiān)會的39號文件也堅定了傳統(tǒng)企業(yè)的去IOE決心。
去IOE風潮顯現(xiàn)，1大幫的公司開始進入到這個領(lǐng)域，希望借助這陣風來大賺1筆。這點本無可非議，市場與技術(shù)相輔相成。但是，有1個非常不好的現(xiàn)象是，很多公司是為了逢迎某些領(lǐng)導的需要，而不是真實的為傳統(tǒng)企業(yè)構(gòu)建面向互聯(lián)網(wǎng)+的安全可控的技術(shù)架構(gòu)。而這其中有著1些不為人知的因素。
首當其沖的是領(lǐng)導們的績效，傳統(tǒng)企業(yè)做事，以績效為導向，這與互聯(lián)網(wǎng)行業(yè)并沒有不同。但是互聯(lián)網(wǎng)行業(yè)有著技術(shù)積累，而且對技術(shù)的選型與轉(zhuǎn)型有著相當?shù)哪托模瑥奶詫毴?a href="http://www.vxbq.cn/oracle/" target="_blank">Oracle用了3，4年就能夠看出。而目前擺在傳統(tǒng)企業(yè)領(lǐng)導眼前的現(xiàn)實卻是，有ZF文件要求各銀行業(yè)金融機構(gòu)對安全可控信息技術(shù)的利用以不低于15％的比例逐年增加，直至2019年到達不低于75％的整體占比。
有1些傳統(tǒng)企業(yè)的朋友，領(lǐng)導要求他們用PostgreSQL替換Oracle數(shù)據(jù)庫，緣由在于這是“最快”的替換Oracle本錢，但是他們站在IT從業(yè)人員的角度來看這件事是不對的，有種敢怒不敢言。固然，這其中也有部份商業(yè)公司在其中推動的關(guān)系。但是明白人心里都知道，PostgreSQL國內(nèi)從業(yè)人員寥寥，之前在中國沒有大范圍的使用經(jīng)驗與架構(gòu)設計，大多停留在找個文檔折騰下的水平上。所謂“最快”的替換方案僅是由于不用進行存儲進程的移植，如果只是這樣使用PostgreSQL，那末僅是應付上層的文件，而沒有真正領(lǐng)會到文件的精神。更有商業(yè)公司號稱有PostgreSQL的專家，但是非常經(jīng)不起斟酌，玩過GreenPlum的就是PostgreSQL專家？而且GreenPlum也僅做研究性質(zhì)的用處？與專家交換后發(fā)現(xiàn)其對鎖與并發(fā)，高可用這塊的掌握更是讓人觸目驚心。
所以筆者1再和身旁的朋友說，去IOE不是1件一揮而就的事情，需要給MySQL時間，否則這件好事情會像著另外一個方向而發(fā)展，乃至重復當年年Sybase替換Oracle的事件產(chǎn)生。但是好消息是這次的上層領(lǐng)導們終究開始認識到互聯(lián)網(wǎng)的重要性，理解了安全可控對1個國家的重要性，而互聯(lián)網(wǎng)公司的成熟經(jīng)驗具有很好的鑒戒意義。

總結(jié)

MySQL數(shù)據(jù)庫早已不是原來的迷你數(shù)據(jù)庫，其在功能性與性能方面都已大幅提升，隨著SSD的突起，MySQL數(shù)據(jù)庫已完全可以替換Oracle數(shù)據(jù)，而PostgreSQL還需要很長的路要走。但市場是開放的，就像Oracle稱雄的年代，還有DB2，Sybase這樣的數(shù)據(jù)庫與之1較長短。我相信互聯(lián)網(wǎng)時期，仍然是百花齊放的年代，沒有誰可以1直占據(jù)優(yōu)勢，即使是MySQL也沒有這個能力。

由于centos剛安裝完后它的yum repo不1定為最新，為保持今后使用yum安裝的各類軟件始終為最新最穩(wěn)定版，請升級你的yum。

另外，如果不及時升級yum有時還會碰到在yum install時系統(tǒng)提示“找不到相干的安裝包”這樣的毛病。

安裝mysql

在等待了1番時間后，yum會幫我們選擇好安裝mysql數(shù)據(jù)庫所需要的軟件和其它附屬的1些軟件。

在此，我安裝的是mysql5.1，讀者可以根據(jù)自己的實際環(huán)境如：centos7.x的環(huán)境下將安裝更高版的mySQL。
當出現(xiàn)下面的結(jié)果時，就代表mysql數(shù)據(jù)庫安裝成功了。

你可使用以下命令啟動和停止mySQL。
啟動：

停止：

重啟：

mySQL的配置與優(yōu)化

配件文件所在路徑

mySQL安裝完后會生成以下幾個重要目錄：

修改my.cnf文件，先來看看我本機的my.cnf的配置

innodb_buffer_pool_size=1024Mslow_query_loglog-short-format slow_query_log_file=/var/log/mysqld-slow-query.log long-query-time = 2 #log-long-format #log-slow-admin-statementslog-queries-not-using-indexes[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid
東西很多，不要急，下面我們1個個參數(shù)來作說明。

對參數(shù)說明，為了便于學習而不是塞填鴨式的教育，我把它分為了1個簡版，1個升級版，

• 簡版的參數(shù)說明： 適用于1般開發(fā)、測試迅速搭建mysql環(huán)境。
• 升級版的參數(shù)說明：適用于1般DBA和架構(gòu)師級別。
  

1口氣寫了這么多，呵呵！
每個參數(shù)我都作了注解，這樣看起來不知道大家是否是會覺得更實用些？
下面，我們就來1個“升級”版的，所謂升級版內(nèi)容1定會很豐富，我總結(jié)了差不多有77條，下面我們就1條條來看吧，這也是本文幾個核心價值中的1個重要部份。

1. [client]
2. port   = 3306 # 客戶端端口號為3306
3. socket  = /data/3306/mysql.sock
4. default-character-set = utf8 
# 客戶端字符集,(控制character_set_client、character_set_connection、character_set_results)
5. [mysql]
6. no-auto-rehash  # 僅僅允許使用鍵值的updates和deletes
7. [mysqld]  
# 組包括了mysqld服務啟動的參數(shù)，它觸及的方面很多，其中有MySQL的目錄和文件，通訊、網(wǎng)絡、信息安全，內(nèi)存管理、優(yōu)化、查詢緩存區(qū)，還有MySQL日志設置等。
8. user    = mysql
# mysql_safe腳本使用MySQL運行用戶(編譯時--user=mysql指定),推薦使用mysql用戶。
9. port    = 3306
# MySQL服務運行時的端口號。建議更改默許端口,默許容易遭受攻擊。
10. socket  = /data/3306/mysql.sock  
# socket文件是在Linux/Unix環(huán)境下獨有的，用戶在Linux/Unix環(huán)境下客戶端連接可以不通過TCP/IP網(wǎng)絡而直接使用unix socket連接MySQL。
11. basedir = /application/mysql  
# mysql程序所寄存路徑,經(jīng)常使用于寄存mysql啟動、配置文件、日志等
12. datadir = /data/3306/data  
# MySQL數(shù)據(jù)寄存文件(極為重要)
13. character-set-server = utf8  
# 數(shù)據(jù)庫和數(shù)據(jù)庫表的默許字符集。(推薦utf8,以避免致使亂碼)
14. log-error=/data/3306/mysql.err
# mysql毛病日志寄存路徑及名稱(啟動出現(xiàn)毛病1定要看毛病日志,百分之百都能通錯誤誤日志排插解決。)
15. pid-file=/data/3306/mysql.pid  
# MySQL_pid文件記錄的是當前mysqld進程的pid，pid亦即ProcessID。
16. skip-locking
# 避免MySQL的外部鎖定，減少出錯概率，增強穩(wěn)定性。
17. skip-name-resolv
# 制止MySQL對外部連接進行DNS解析，使用這1選項可以消除MySQL進行DNS解析的時候。但是需要注意的是，如果開啟該選項，則所有遠程主機連接授權(quán)都要使用IP地址方式了，否則MySQL將沒法正常處理連接要求！
18. skip-networking  
# 開啟該選項可以完全關(guān)閉MySQL的TCP/IP連接方式，如果Web服務器是以遠程連接的方式訪問MySQL數(shù)據(jù)庫服務器的，則不要開啟該選項，否則沒法正常連接！
19. open_files_limit    = 1024
# MySQLd能打開文件的最大個數(shù),如果出現(xiàn)too mant open files之類的就需要調(diào)劑該值了。
20. back_log = 384  
# back_log參數(shù)是值指出在MySQL暫時停止響應新要求之前，短時間內(nèi)的多少個要求可以被存在堆棧中。如果系統(tǒng)在短時間內(nèi)有很多連接，則需要增加該參數(shù)的值，該參數(shù)值指定到來的TCP/IP連接的監(jiān)聽隊列的大小。不同的操作系統(tǒng)在這個隊列的大小上有自己的限制。如果試圖將back_log設置得高于操作系統(tǒng)的限制將是無效的，其默許值為50.對Linux系統(tǒng)而言，推薦設置為小于512的整數(shù)。
21. max_connections = 800
# 指定MySQL允許的最大連接進程數(shù)。如果在訪問博客時常常出現(xiàn) Too Many Connections的毛病提示，則需要增大該參數(shù)值。
22. max_connect_errors = 6000  
# 設置每一個主機的連接要求異常中斷的最大次數(shù)，當超過該次數(shù)，MySQL服務器將制止host的連接要求，直到MySQL服務器重啟或通過flush hosts命令清空此host的相干信息。
23. wait_timeout = 120  
# 指定1個要求的最大連接時間，對4GB左右內(nèi)存的服務器來講，可以將其設置為5~10。
24. table_cache = 614K  
# table_cache唆使表高速緩沖區(qū)的大小。當MySQL訪問1個表時，如果在MySQL緩沖區(qū)還有空間，那末這個表就被打開并放入表緩沖區(qū)，這樣做的好處是可以更快速地訪問表中的內(nèi)容。1般來講，可以查看數(shù)據(jù)庫運行峰值時間的狀態(tài)值Open_tables和Open_tables，用以判斷是不是需要增加table_cache的值，即如果Open_tables接近table_cache的時候，并且Opened_tables這個值在逐漸增加，那就要斟酌增加這個值的大小了。
25. external-locking = FALSE  
# MySQL選項可以免外部鎖定。True為開啟。
26. max_allowed_packet =16M  
# 服務器1次能處理最大的查詢包的值，也是服務器程序能夠處理的最大查詢
27. sort_buffer_size = 1M  
# 設置查詢排序時所能使用的緩沖區(qū)大小，系統(tǒng)默許大小為2MB。
# 注意：該參數(shù)對應的分配內(nèi)存是每一個連接獨占的，如果有100個連接，那末實際分配的總排序緩沖區(qū)大小為100 x6=600MB。所以，對內(nèi)存在4GB左右的服務器來講，推薦將其設置為6MB~8MB
28. join_buffer_size = 8M
# 聯(lián)合查詢操作所能使用的緩沖區(qū)大小，和sort_buffer_size1樣，該參數(shù)對應的分配內(nèi)存也是每一個連接獨享。
29. thread_cache_size = 64
# 設置Thread Cache池中可以緩存的連接線程最大數(shù)量，可設置為0~16384，默許為0.這個值表示可以重新利用保存在緩存中線程的數(shù)量，當斷開連接時如果緩存中還有空間，那末客戶真?zhèn)€線程將被放到緩存中;如果線程重新被要求，那末要求將從緩存中讀取,如果緩存中是空的或是新的要求，那末這個線程將被重新創(chuàng)建，如果有很多線程，增加這個值可以改良系統(tǒng)性能。通過比較Connections和Threads_created狀態(tài)的變量，可以看到這個變量的作用。我們可以根據(jù)物理內(nèi)存設置規(guī)則以下:1GB內(nèi)存我們配置為8,2GB內(nèi)存我們配置為16,3GB我們配置為32,4GB或4GB以上我們給此值為64或更大的值。
30. thread_concurrency = 8  
# 該參數(shù)取值為服務器邏輯CPU數(shù)量x 2，在本例中，服務器有兩個物理CPU，而每一個物理CPU又支持H.T超線程，所以實際取值為4 x 2 = 8。這也是雙4核主流服務器的配置。
31. query_cache_size = 64M
# 指定MySQL查詢緩沖區(qū)的大小。可以通過在MySQL控制臺視察，如果Qcache_lowmem_prunes的值非常大，則表明常常出現(xiàn)緩沖不夠的情況;如果Qcache_hits的值非常大，則表明查詢緩沖使用得非常頻繁。另外如果改值較小反而會影響效力，那末可以斟酌不用查詢緩沖。對Qcache_free_blocks，如果該值非常大，則表明緩沖區(qū)中碎片很多。
32. query_cache_limit = 2M  
# 只有小于此設置值的結(jié)果才會被緩存
33. query_cache_min_res_unit = 2k  
# 設置查詢緩存分配內(nèi)存的最小單位，要適當?shù)谠O置此參數(shù)，可以做到為減少內(nèi)存快的申請和分配次數(shù)，但是設置過大可能致使內(nèi)存碎片數(shù)值上升。默許值為4K，建議設置為1K~16K。
34. default_table_type = InnoDB  
# 默許表的類型為InnoDB
35. thread_stack = 256K  
# 設置MySQL每一個線程的堆棧大小，默許值足夠大，可滿足普通操作。可設置范圍為128KB至4GB，默許為192KB
#transaction_isolation = Level
# 數(shù)據(jù)庫隔離級別 (READ UNCOMMITTED(讀取未提交內(nèi)容) READ COMMITTED(讀取提交內(nèi)容) REPEATABLE
READ(可重讀) SERIALIZABLE(可串行化))
36. tmp_table_size = 64M  
# 設置內(nèi)存臨時表最大值。如果超過該值，則會將臨時表寫入磁盤，其范圍1KB到4GB。
37. max_heap_table_size = 64M  
# 獨立的內(nèi)存表所允許的最大容量。
38. table_cache = 614
# 給常常訪問的表分配的內(nèi)存，物理內(nèi)存越大，設置就越大。調(diào)大這個值，1般情況下可以下降磁盤IO，但相應的會占用更多的內(nèi)存,這里設置為614。
39. table_open_cache = 512  
# 設置表高速緩存的數(shù)目。每一個連接進來，都會最少打開1個表緩存。因此， table_cache 的大小應與 max_connections 的設置有關(guān)。例如，對 200 個并行運行的連接，應當讓表的緩存最少有 200 × N ，這里 N 是利用可以履行的查詢的1個聯(lián)接中表的最大數(shù)量。另外，還需要為臨時表和文件保存1些額外的文件描寫符。
40. long_query_time = 1  
# 慢查詢的履行用時上限,默許設置是10s,推薦(1s~2s)
41. log_long_format  
# 沒有使用索引的查詢也會被記錄。(推薦,根據(jù)業(yè)務來調(diào)劑)
42. log-slow-queries = /data/3306/slow.log  
# 慢查詢?nèi)罩疚募窂?如果開啟慢查詢,建議打開此日志)
43. log-bin = /data/3306/mysql-bin  
# logbin數(shù)據(jù)庫的操作日志,例如update、delete、create等都會存儲到binlog日志,通過logbin可以實現(xiàn)增量恢復
44. relay-log = /data/3306/relay-bin
# relay-log日志記錄的是從服務器I/O線程將主服務器的2進制日志讀取過來記錄到從服務器本地文件,然后SQL線程會讀取relay-log日志的內(nèi)容并利用到從服務器
45. relay-log-info-file = /data/3306/relay-log.info  
# 從服務器用于記錄中繼日志相干信息的文件,默許名為數(shù)據(jù)目錄中的relay-log.info。
46. binlog_cache_size = 4M  
# 在1個事務中binlog為了記錄sql狀態(tài)所持有的cache大小，如果你常常使用大的，多聲明的事務，可以增加此值來獲得更大的性能，所有從事務來的狀態(tài)都被緩沖在binlog緩沖中，然后再提交后1次性寫入到binlog中，如果事務比此值大，會使用磁盤上的臨時文件來替換，此緩沖在每一個鏈接的事務第1次更新狀態(tài)時被創(chuàng)建。
47. max_binlog_cache_size = 8M  
# 最大的2進制Cache日志緩沖尺寸。
48. max_binlog_size = 1G  
# 2進制日志文件的最大長度(默許設置1GB)1個2進制文件信息超過了這個最大長度之前,MySQL服務器會自動提供1個新的2進制日志文件接續(xù)上。
49. expire_logs_days = 7  
# 超過7天的binlog,mysql程序自動刪除(如果數(shù)據(jù)重要,建議不要開啟該選項)
50. key_buffer_size = 256M  
# 指定用于索引的緩沖區(qū)大小，增加它可得到更好的索引處理性能。對內(nèi)存在4GB左右的服務器來講，該參數(shù)可設置為256MB或384MB。
# 注意：如果該參數(shù)值設置得過大反而會使服務器的整體效力下降！
51. read_buffer_size = 4M  
# 讀查詢操作所能使用的緩沖區(qū)大小。和sort_buffer_size1樣，該參數(shù)對應的分配內(nèi)存也是每一個連接獨享。
52. read_rnd_buffer_size = 16M
# 設置進行隨機讀的時候所使用的緩沖區(qū)。此參數(shù)和read_buffer_size所設置的Buffer相反，1個是順序讀的時候使用，1個是隨機讀的時候使用。但是二者都是針對與線程的設置，每一個線程都可以產(chǎn)生兩種Buffer中的任何1個。默許值256KB，最大值4GB。
53. bulk_insert_buffer_size = 8M  
# 如果常常性的需要使用批量插入的特殊語句來插入數(shù)據(jù),可以適當調(diào)劑參數(shù)至16MB~32MB,建議8MB。
54. myisam_sort_buffer_size = 8M
# 設置在REPAIR Table或用Create index創(chuàng)建索引或 Alter table的進程中排序索引所分配的緩沖區(qū)大小，可設置范圍4Bytes至4GB，默許為8MB
55. lower_case_table_names = 1  
# 實現(xiàn)MySQL不辨別大小。(發(fā)開需求-建議開啟)
56. slave-skip-errors = 1032,1062  
# 從庫可以跳過的毛病數(shù)字值(mysql毛病以數(shù)字代碼反饋,全的mysql毛病代碼大全,以后會發(fā)布至博客)。
57. replicate-ignore-db=mysql  
# 在做主從的情況下,設置不需要同步的庫。
58. server-id = 1  
# 表示本機的序列號為1,如果做主從，或多實例,serverid1定不能相同。
59. myisam_sort_buffer_size = 128M
# 當需要對履行REPAIR, OPTIMIZE, ALTER 語句重建索引時，MySQL會分配這個緩存，和LOAD DATA INFILE會加載到1個新表，它會根據(jù)最大的配置認真的分配的每一個線程。
60. myisam_max_sort_file_size = 10G
# 當重新建索引（REPAIR，ALTER，TABLE，或LOAD，DATA，TNFILE）時，MySQL被允許使用臨時文件的最大值。
61. myisam_repair_threads = 1
# 如果1個表具有超過1個索引, MyISAM 可以通過并行排序使用超過1個線程去修復他們.
62. myisam_recover
# 自動檢查和修復沒有適當關(guān)閉的 MyISAM 表.
63. innodb_additional_mem_pool_size = 4M  
# 用來設置InnoDB存儲的數(shù)據(jù)目錄信息和其他內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存池大小。利用程序里的表越多，你需要在這里面分配越多的內(nèi)存。對1個相對穩(wěn)定的利用，這個參數(shù)的大小也是相對穩(wěn)定的，也沒有必要預留非常大的值。如果InnoDB用廣了這個池內(nèi)的內(nèi)存，InnoDB開始從操作系統(tǒng)分配內(nèi)存，并且往MySQL毛病日志寫正告信息。默許為1MB，當發(fā)現(xiàn)毛病日志中已有相干的正告信息時，就應當適當?shù)脑黾釉搮?shù)的大小。
64. innodb_buffer_pool_size = 64M  
# InnoDB使用1個緩沖池來保存索引和原始數(shù)據(jù)，設置越大，在存取表里面數(shù)據(jù)時所需要的磁盤I/O越少。強烈建議不要果斷地將InnoDB的Buffer Pool值配置為物理內(nèi)存的50%~80%，應根據(jù)具體環(huán)境而定。
65. innodb_data_file_path = ibdata1:128M:autoextend  
# 設置配置1個可擴大大小的尺寸為128MB的單獨文件，名為ibdata1.沒有給出文件的位置，所以默許的是在MySQL的數(shù)據(jù)目錄內(nèi)。
66. innodb_file_io_threads = 4  
# InnoDB中的文件I/O線程。通常設置為4，如果是windows可以設置更大的值以提高磁盤I/O
67. innodb_thread_concurrency = 8  
# 你的服務器有幾個CPU就設置為幾，建議用默許設置，1般設為8。
68. innodb_flush_log_at_trx_commit = 1  
# 設置為0就等于innodb_log_buffer_size隊列滿后在統(tǒng)1存儲，默許為1，也是最安全的設置。
69. innodb_log_buffer_size = 2M  
# 默許為1MB，通常設置為8~16MB就足夠了。
70. innodb_log_file_size = 32M  
# 肯定日志文件的大小，更大的設置可以提高性能，但也會增加恢復數(shù)據(jù)庫的時間。
71. innodb_log_files_in_group = 3  
# 為提高性能,MySQL可以以循環(huán)方式將日志文件寫到多個文件。推薦設置為3。
72. innodb_max_dirty_pages_pct = 90  
# InnoDB主線程刷新緩存池中的數(shù)據(jù)。
73. innodb_lock_wait_timeout = 120  
# InnoDB事務被回滾之前可以等待1個鎖定的超時秒數(shù)。InnoDB在它自己的鎖定表中自動檢測事務死鎖并且回滾事務。InnoDB用locak tables 語句注意到鎖定設置。默許值是50秒。
74. innodb_file_per_table = 0  
# InnoDB為獨立表空間模式，每一個數(shù)據(jù)庫的每一個表都會生成1個數(shù)據(jù)空間。0關(guān)閉，1開啟。
# 獨立表空間優(yōu)點：
# 1、每一個表都有自己獨立的表空間。
# 2 、每一個表的數(shù)據(jù)和索引都會存在自己的表空間中。
# 3、可以實現(xiàn)單表在不同的數(shù)據(jù)庫中移動。
# 4、空間可以回收（除drop table操作處，表空不能自己回收。）
75. [mysqldump]


76. quick
#quick  不緩沖查詢，直接導出至stdout
77. max_allowed_packet = 2M  
# 設定在網(wǎng)絡傳輸中1次消息傳輸量的最大值。系統(tǒng)默許值為1MB，最大值是1GB，必須設置為1024的倍數(shù)。單位為字節(jié)。

mySQL安裝完后，默許只能在本機進行SQL客戶真?zhèn)€訪問，如果你要使用1臺遠程主機，比如説：
mySQL安裝在192.168.0.101上，你要通過192.168.0.1上的mySQL客戶端登錄192.168.0.101訪問，默許是不允許的。
為了能夠遠程訪問mySQL你必須配置遠程可連接的用戶信息。
1般來説：
為了簡單，我們可以配置1個用戶，用戶名為“username@%”，這個%代表支持遠程任何IP地址的客戶端可以訪問這臺mySQL主機。
但是，1般來説為了安全，我們會把username@后面跟上1個具體的ip。
所以如果在mySQL剛安裝終了時，root用戶只可以作本地訪問，為了開啟遠程訪問功能我們1般都有1個root@%這樣的用戶名。

操作步驟以下：
1. 先登錄本地mysql通過命令：

2. 在mysql命令符內(nèi)履行以下語句:

在我的配置中有這么1段描寫

此處注意了，網(wǎng)上對“慢查詢”的配置，很多都已deprecated了，請參照我上述這類寫法。

我們配置完后使用service mysqld restart重啟mysql服務后，我們可以看到在/var/log目錄下面會有1個mysqld-slow-query.log的文件 。

我們在sql客戶端履行以下語句

接下去我們來看看這個mysqld-slow-query.log中的文件內(nèi)容：

這樣看，仿佛有1些不太習慣對不對？
如果這個日志文件中有成千上百個日志，我們?nèi)绻枰y(tǒng)計 Top10最慢的那些SQL分別是哪些。。。怎樣辦？
我們可使用mysqldumpslow命令

這個問題，我曾在面試時碰到過有人説“精通MYSQL“，因而我問了他們這么1個問題，結(jié)果是超過90%的人沒法回答。
mySQL最重要的兩種存儲引擎InnoDB與Myisam，這是基礎(chǔ)，1定要知道，下面來看。

1） 事務處理
innodb 支持事務功能，myisam 不支持。
Myisam 的履行速度更快，性能更好。
2） select ,update ,insert ,delete 操作
MyISAM：如果履行大量的SELECT，MyISAM是更好的選擇
InnoDB：如果你的數(shù)據(jù)履行大量的INSERT或UPDATE，出于性能方面的斟酌，應當使用InnoDB表
3） 鎖機制不同
InnoDB 為行級鎖，myisam 為表級鎖。
注意：當數(shù)據(jù)庫沒法肯定，所找的行時，也會變成鎖定全部表。
如： update table set num = 10 where username like "%test%";
4） 查詢表的行數(shù)不同
MyISAM：select count(*) from table,MyISAM只要簡單的讀出保存好的行數(shù)，注意的是，當count(*)語句包括   where條件時，兩種表的操作是1樣的
InnoDB ： InnoDB 中不保存表的具體行數(shù)，也就是說，履行select count(*) from table時，InnoDB要掃描1遍全部表來計算有多少行
5） 物理結(jié)構(gòu)不同

MyISAM ：每一個MyISAM在磁盤上存儲成3個文件。第1個文件的名字以表的名字開始，擴大名指出文件類型。

• .frm文件存儲表定義。
• 數(shù)據(jù)文件的擴大名為.MYD (MYData)。
• 索引文件的擴大名是.MYI (MYIndex)

6） anto_increment 機制不同

這是1道很早的面試題：

1張表,里面有ID自增主鍵,當insert了17條記錄以后,刪除第15,16,17條記錄,再把Mysql重啟,再insert1條記錄,這條記錄的ID是18還是15 。

答案：
如果表的類型是MyISAM，那末是18。 
由于MyISAM表會把自增主鍵的最大ID記錄到數(shù)據(jù)文件里，重啟MySQL自增主鍵的最大ID也不會丟失。 
如果表的類型是InnoDB，那末是15。 
InnoDB表只是把自增主鍵的最大ID記錄到內(nèi)存中，所以重啟數(shù)據(jù)庫或是對表進行OPTIMIZE操作，都會致使最大ID丟失。

其他） 為何MyISAM會比Innodb 的查詢速度快。
INNODB在做SELECT的時候，要保護的東西比MYISAM引擎多很多；

• 數(shù)據(jù)塊，INNODB要緩存，MYISAM只緩存索引塊，  這中間還有換進換出的減少； 
• innodb尋址要映照到塊，再到行，MYISAM 記錄的直接是文件的OFFSET，定位比INNODB要快；
• INNODB還需要保護MVCC1致；雖然你的場景沒有，但他還是需要去檢查和保護；
• MVCC ( Multi-Version Concurrency Control )多版本并發(fā)控制 

InnoDB必須找到1個行的版本，它最少要和事務的版本1樣老(也即它的版本號不大于事務的版本號)。這保證了不論是事務開始之前，或事務創(chuàng)建時，或修改了這行數(shù)據(jù)的時候，這行數(shù)據(jù)是存在的。

這行數(shù)據(jù)的刪除版本必須是未定義的或比事務版本要大。這可以保證在事務開始之前這行數(shù)據(jù)沒有被刪除。

MySQL 的 Query Profiler 是1個使用非常方便的 Query 診斷分析工具，通過該工具可以獲得1條Query 在全部履行進程中多種資源的消耗情況，如 CPU，IO，IPC，SWAP 等，和產(chǎn)生的 PAGE FAULTS，CONTEXT SWITCHE 等等，同時還能得到該 Query 履行進程中 MySQL 所調(diào)用的各個函數(shù)在源文件中的位置。
MySQL5.0.37版本以上支持PROFILING調(diào)試功能，讓您可以了解SQL語句消耗資源的詳細信息。由于它需要調(diào)用系統(tǒng)的getrusage()函數(shù)，所以只是在Linux/Unix類平臺上才能使用，而不能在Windows平臺上使用。而且，PROFILING是針對處理進程(process)而不是線程(thread)的，服務器上的其他利用，可能會影響您的調(diào)試結(jié)果，因此，這個工具合適開發(fā)進程中的調(diào)試，如果要在生產(chǎn)環(huán)境中調(diào)試使用，則要注意它的局限性。

為避免之前已把 SQL 寄存在 QCACHE 中， 建議在履行 SQL 時， 強迫 SELECT 語句不進行 QCACHE 檢測。這樣可以提交分析的準確性。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈