上海MYSQL大會摘要

【譚俊青：MyISAM和InnoDB的比較】MySQL儲存引擎圖，使用最多的是MyISAM。一般愛可生推薦InnoDB給客戶。MyISAM儲存構成：3個檔案（tableName.frm, tableName.MYD, tableNameMYI），不支援事務，表鎖。

 

【譚俊青：MyISAM和InnoDB的比較】MyISAM行儲存格式 1 定長-表結構中沒有變長欄位，預設就是定長儲存。好處（高效能，更好的恢複能力，不需整理） 2 變長-表結構如果包含varchar, varbinary, blob, test等欄位，則以變長儲存。壞處（可能造成片段，增加恢複難度）3 壓縮格式-唯讀格式

 

成江東：盛大糖果社區的幾個問題 1 並發壓力快速提高？ 2 需求變化快？ 3 資料水平分割？NOSQL資料庫能否解決這幾個問題。

 

成江東：議題：MongoDB是什麼、特性，適用情境，與其他資料庫的對比。NOSQL資料庫是非關係型的資料庫，主要用於社區類web2.0網站。主要解決1 對資料庫高並發的需求 2 對海量資料的高效率儲存和訪問的需求 3 對資料庫的高可擴充性和高可用性的需求。

 

 mongoDB是什嗎？ CAP理論-魚與熊掌不可得兼。一致性（C)，分區容忍性（P），可用性（A)。一個分散式資料庫最多隻能同時滿足兩個。1) CA 傳統關聯式資料庫 2) AP：key-value資料庫

 

因此，根據CAP理論。mongoDB不能解決：資料庫事務一致性需求 2 資料庫的寫即時性等。MongoDB是一個介於關聯式資料庫和非關聯式資料庫之間的產品，是非關聯式資料庫當中功能最豐富，最像關聯式資料庫的。他支援的資料結構非常鬆散，是類似 json的bjson格式，因此可以儲存比較複雜的資料類型。

 

mongoDB使用JSON格式文檔資料庫，文檔（document），集合。自由資料模式：支援在對象和數組中嵌入其他的對象和數組，mongo模式設計中的一個關鍵問題就是值得為這個對象建立一個集合呢？還是把這個對象嵌入到其他的集合中。

 

mongoDB的索引設計很重要，支援很全面。包括基本索引， 唯一索引，內嵌文檔中key，文檔本身，複合索引，線上索引。

 

mongoDB複製和自動分區帶來的高可用性。一個失效，自動切換到另外可用的伺服器上，幾個伺服器形成分區叢集，2個以上的shards，1個以上的config servers，和任意數量的mongos servers組成，應用程式串連mongos servers。

 

找了5台伺服器進行了類比測試，一個php指令碼。發現在初期，分布不均勻，第一台DB上有100多萬條，另外2,3台都是30萬條左右，增加一台伺服器，增加到500萬條以後，探索資料已經變為非常均勻的

 

mongoDB的豐富的查詢語句：in查詢，排序u，exists，查詢分區，count，正則，遊標，類型匹配，數組元素個數。

 

mongoDB Map/reduce是彙總和過濾資料的工具。mongoDB的效能優異（並發效能有1.5萬多秒，無外鍵約束，五事務，非同步寫磁碟。） 還有其他特性（GridFS，使用方便，會自動建立資料庫db和集合collection，無需顯式執行。）

 

mongoDB的適用情境 1 結構不固定，有資料嵌套 2 要求高並發性 3 經常需要做資料水平分割 4 記憶體大於資料量（推薦） 不足之處 1 比較佔用磁碟空間，效能受記憶體影響 2 效能依賴記憶體，同時無法指定記憶體大小，容易被其他程式佔用 3 不支援事務，不支援join 4 每個document限制最大不超過4MB

 

為什麼選擇mongoDB？效能優異，擴充力強，面向文檔，部署簡單，功能全面，易於開發，支援全面。郵件組google groups mongodb-user， 豆瓣小組 mongoDB。

 

其他的nosql資料庫簡要分析：redis可以被看成加強版的memcache，redis和tokyo cabinet，沒有mongoDB的自動分區技術，tokyo cabinet是個人維護的，在盛大超過1億記錄測試時候有效能問題。在盛大糖果中有部分應用用到。Cassandra查詢不夠豐富，穩定性較差。

 

糖果社區有少數應用在用Tokoy Cabinet, 已經嘗試mongoDB，將增加一下應用的部署。當然，主要還是在使用MySQL。應該是與MySQL結合起來，互補優勢，得到綜合的效益。

 

最佳化包括：表設計，索引規劃，語句最佳化，預存程序，觸發器，視圖。1 表設計：命名規則（不用保留字，多位元組字元），欄位類型（數值，字元，二進位，時間，其他）要合適，主要關注效能，磁碟儲存，資料精確度等做個平衡選擇。比如精確浮點數必須是decimal, 實際上是字元型儲存,效能差。

 

1表設計續：引擎選擇，MyISAM （快讀，高壓縮比 表鎖）； InnoDB （事務支援，外鍵支援，行鎖，熱備支援）；memory （記憶體資料，表鎖）；InnoDB是單機版唯一支援事務的引擎。Memory的安全性查，記憶體出錯就完蛋，但是IO效能肯定很高。

 

1表設計續-引擎介紹：最可靠的引擎 NDB（MySQL Cluster）：支援事務，高並發寫，Key-Value 可持續化，99.999%的高可靠性。Archive：比MyISAM更高的壓縮比，缺點很多（只能插入，不支援主鍵）。CSV是EXCEL和MySQL之間溝通的橋樑 BlackHole：緩解Replication中主的壓力。

 

1表設計續：【編碼選擇】單位元組，多位元組；經常有亂碼出現，原因是匯出檔案，終端系統字元集不支援，再匯入到新資料庫中，就變成亂碼了。【索引規劃】唯一索引，普通索引，部分索引，聚簇索引，外鍵；外鍵只有innoDB支援，盡量不要隨便用外鍵，會影響效能。

 

【語句最佳化】關注回應時間，整個時間包括執行時間和傳送時間，需要不斷研究最佳化。語句最佳化的一些好習慣，1) 如果能不再SQL使用內建函式，就不要用; 2) 用join比where效能好; 3) 注意類型匹配，整型不用'', 如'15'和15; 4) 通過增加欄位如 column_length，代替column(length);

 

語句最佳化 5）like 'de' 可以寫為 >='de' and <= 'df'；6）去掉不必要的暫存資料表和不必要的欄位，排序等；7）缺乏必要的過濾條件；8）MySQL5.5之前對子查詢處理不夠最佳化，不如JOIN語句快；9）不同類型的欄位做關聯查詢，需要修改欄位類型為一致；10）多記錄某一條精確定位慢。

 

 語句最佳化：11)對複雜查詢中，多個欄位從一個表中選取，表掃描次數過多，IO操作多，影響速度；

 

使用摘要表 優點：減少對原磁碟表的訪問 缺點：要做適當的更新。經常更新的資料，可能不合適。比如對於報告表就比較合適。

 

 寫語句最佳化 觸發器的最佳化，特點：行級，臨時行表，前置、後置。視圖盡量不要用，對效能很差，因為不用索引。即使要用視圖，限制也很多，時間關係不多講。

 

MySQL Replication 非同步資料複製，負載平衡；線上熱備，水平擴充；跨網資料複製；Fail Over --- 手動切換。可能6種複製方案，1主1從，1主2從，2主1從（不好，不推薦），1主1從2從 點對點複寫 1主1主（可能有問題） 三個彼此複製，1主1主1主（可能有問題）

 

MySQL Replication 在Scale out時候效能是不錯的，可以分步實施到多個Slave機器上。Slave可以作為線上熱備的功能。當主要資料庫出問題，可以手動設定，把主上的操作全部切換到從機上，保證對外部的訪問

 

MySQL Cluster 特點 1)無共用儲存的資料存放區模式;2)即時同步資料;3)特有應用下的高效能，高事務輸送量;4)無特殊硬體需求;5)記憶體儲存資料&硬碟儲存資料(5.1版本) 6)Fail Over-- 快速，自動; 7)資料節點間心跳機制；

 

MySQL Cluster資料是按照主伺服器的方式來儲存的，在每一個主裡面的資料節點上，都是通過另外的資料節點來提供副本的，一個節點出了問題，還是會能繼續服務的。極端情況下，2個點點壞了，或者一個節點的部分和另一節點的其他部分壞了，又該如何考慮呢？

一般，2個管理節點，就可以滿足管理叢集的需求。但是2個節點壞了，需要第三種高可用性解決方案，MySQL Cluster with Replication. 還作為異地備份的容災備份。

 

Heartbeat & MySQL Replication 1)心跳機制-資源故障切換的安全管理；2) 虛擬IP管理--對應用訪問資料庫透明化; 在主從之間加了heartbeat軟體，提供自動切換機制。

 

Heartbeat, Block and MySQL Replication 分布式塊複製（DRBD）運行在標準網路通訊協定上。通過網路IO提供資料轉送，有時候比同步還快。在Active出問題後，必須進行資料同步，修複後切換回修複後的伺服器。

 

 MySQL with Shared Storage 1) Active/passive 多執行個體訪問同一份資料檔案 2) 特點: 較高的成本開銷 同時把資料存放區在共用儲存SAN裡面。

 

以上內容來自 新浪 @thinkinlamp 的圍脖