面向讀者

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

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

下圖是1個mySQL在大型網站和系統中的利用案例統計。

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

MYSQL

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

下圖是1個mySQL在大型網站和系統中的利用案例統計。

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

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

總結

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

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

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

安裝mysql

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

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

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

停止：

重啟：

mySQL的配置與優化

配件文件所在路徑

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個個參數來作說明。

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

• 簡版的參數說明： 適用于1般開發、測試迅速搭建mysql環境。
• 升級版的參數說明：適用于1般DBA和架構師級別。
  

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


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

mySQL安裝完后，默許只能在本機進行SQL客戶真個訪問，如果你要使用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命令符內履行以下語句:

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

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

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

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

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

這樣看，仿佛有1些不太習慣對不對？
如果這個日志文件中有成千上百個日志，我們如果需要統計 Top10最慢的那些SQL分別是哪些。。。怎樣辦？
我們可使用mysqldumpslow命令

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

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

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

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

6） anto_increment 機制不同

這是1道很早的面試題：

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

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

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

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

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

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

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

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

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