我在這裡將討論一些關於MySQL的面向企業級應用的思路，以及能否用MySQL替代當前Oracle的問題。
首先說明一點的是,我不是說MySQL沒有大企業級的應用，事實上，可以看到越來越多的成功布署MySQL的應用，但是，還不夠多，還有許多大企業的關鍵應用還不敢用MySQL。或許這篇小文能和大家一起探討一些比較"虛"的東西。
存儲引擎
由於MySQL自己一直沒有一個成熟可靠的存儲引擎，估計這讓他們深感痛處(尤其是目前最成熟的事務型引擎InnoDB又在Oracle手裡)。MySQL寄予厚望的Falcon在開發了兩年多之後，建樹不大，而該項目帶頭人Jim Starkey前不久又離開了MySQL，陋屋偏逢連夜雨。
Sun會給MySQL一個穩健的引擎麼? 我看短時間內未必能達到。除非，Sun從Oracle手裡把InnoDB買回來。
如果進行大企業級應用，考慮到引擎本身的穩定性，似乎可選的也只有InnoDB了，但InnoDB的備份工具又是收費的。至於MyISAM，盡管有人的確喜歡用，但對於並發能力要求稍微嚴格一點，MyISAM根本不行。
在線DDL鎖表問題
MySQL中，在線對表對象做DDL操作是要鎖表的，對於可用性要求比較高，而應用變化又比較頻繁的環境，這是個非常很糟糕瓶頸。沒想到有什麼好的辦法，除非，像大家開玩笑說的，把所有的表都預留出足夠的空閒列，減少類似增加列的變更麻煩。
這個MySQL天生的缺陷在PostgreSQL中是不存在的，比如創建索引，可以用create INDEX CONCURRENTLY的方式來減小影響。(MySQL後續的版本中在逐漸改善這個問題：添加了 ONLINE 關鍵字)
這個看似是個小問題，但實際上卻是對很多人最為困擾的。
在線備份問題
MySQL 6.0後終於具備在線備份的能力了。但現在，恐怕比較激進的用戶也只能用版本5而已。
很多MySQL資深用戶能夠根據自己應用的特點布署適合自己的備份方式(盡管可能也會有缺陷，比如基於時間點的恢復)。
至於另一個常用來衡量DB可擴展性的特性：分區，現在MySQL已經能夠支持了，盡管實現的的確有點晚。而使用MySQL的用戶，一般都采取Sharding的策略對數據進行切分，所以，分區的問題倒似乎並不是最為關鍵的。
因為是整理思路，這算是這個系列的第一篇。
存儲引擎
繼續上一篇的討論，記錄針對MySQL在大企業級商用上我的一些零星想法。網絡上到處都有關於各個引擎之間的對比。這裡要提醒一點是，注意各個引擎的鎖的粒度。InnoDB 是行鎖，鎖的實現是依賴於索引的，MyISAM只是表鎖。鎖粒度是衡量存儲引擎的一個重要指標，其能力很大程度上決定並發能力。
至於TRANSACTION ISOLATION LEVEL，則是另外一個需要衡量的指標。
老生常談的，某某引擎適合什麼類型的應用，歸根結底還是由於其實現的機制決定了引擎的特性。
存儲層的解決方案
相信沒有人願意在MySQL上用RAW設備，很多人幾乎就是直接把數據文件放在文件系統上(個人認為，對於數據庫這樣的應用來說，文件系統可靠性還有所欠缺)。我還沒發現 MySQL上類似Oracle ASM的解決方案。如果用文件系統，單節點的數據存儲能力肯定要受到制約--沒有人喜歡把幾個T的數據扔到一個MySQL DB上吧? 一旦某個文件系統故障，麻煩就來了。從這個角度考慮，或許LVM2是一個可選的方式。
當然，如果把數據文件扔到SAN上也還不錯。一方面問題是，現在存儲廠商對於MySQL的重視長度還遠不如Oracle、DB2等老牌商業數據庫。另一方面，很多MySQL用戶沒有 SAN 環境的，數據都是在本地磁盤上。
固態硬盤與MySQL
前兩天有朋友在上一篇分析留言，提及應注重閃存的應用。其實還不如布署固態硬盤(SSD)對MySQL可能的影響問題。 相信現在有很多企業需要在DB的IOPS上尋求突破，SSD是個可能的突破口，但從目前我收集到的數據來看，還沒有足夠的數據說明啟用SSD的MySQL能有預期的數量級上的IOPS提升。
商業支持
現在MySQL的背後有Sun ，但是，如果不購買服務的話，到哪裡去找比較正規的商業支持(我是說軟件集成商)? 即使購買了服務，如果問題出在存儲引擎上，MySQL能給即時、有效的技術響應麼? 這也是MySQL沒有自有存儲引擎的一個弱點，因為銜接的環節多，一旦有商務上的問題，很容易陷入扯皮階段。
這是這個系列第二篇。如果有第三篇，我倒是想寫幾點關於MySQL的設想。
