MySQL數據庫不使用的理由，雖然很多理由都是出於誤解的，但是的確存在著一部分很充分的不使用MySQL的理由。當然，現實的情況會根據環境有所不同，但是在每個情況下，我覺得拒絕任何數據庫技術應該基於合理的理由，而不是根據某些疲憊不堪的數據庫管理員(DBA)的意見。為了達到這樣的目的，我在這篇文章中列出了八條不使用MySQL的理由。
首先，不使用某種技術的理由和使用這個技術的理由在本質上不同。常常，反對某些東西的理由會更加讓人注意。我們可能需要幾條理由才會真正的使用這個技術，但是只要一個理由就會讓我們止步。軟件的選擇就是這樣的決定，僅有一個理由是決不足夠促使我們做出肯定的決定，但是一個充分的負面理由會否定很多積極的因素。
雖然有一長串關系數據庫管理系統(RDBMS)可以供我們選擇，但是我將對比限制在幾個最常用的產品上。雖然全面的對比很少，還是存在著很多技術上的比較。在這裡，我們只關心“正規”理由。
MySQL使用GPL
最重要的理由優先。在這裡並不適合GNU General Public License，並且也不應該是數據庫技術的選擇。很明顯，GPL許可證對很多環境是積極的，但是對於其他一些環境，GPL的軟件是沒有希望的。在這些情況下，連PostgreSQL的BSD許可證仍然太“開放”，那麼一個商業的許可證會更加適合。
MySQL不使用GPL
在一些情況下，MySQL是收費的，這樣GPL可能不能很好的服務於這些情況。如果你想要將這個數據庫的許可證和你自己的項目一起銷售，你的項目一定要采用相似的許可證，或者你需要購買商業許可證。如果這個因素改變了你的軟件的銷售方式，你需要處理由於必須支持MySQL的多個版本或者配置而引起的額外的負擔(這會增加終端用戶的成本)，或者存在由於MySQL的使用造成的不合理的影響。在這些情況下，一些軟件分銷商可能傾向於采用其他的產品，比如BSD許可證的PostgreSQL。
和現有環境的集成
我知道大型的IT公司會有Oracle和Sybase的單位軟件使用權(Site License)，以及很多MS-SQL Server的專有許可證(specific license)。在這些公司中，這種MS-SQL的實例主要是各部門的無知職員造成的，他們不知道他們已經花錢購買了其他數據庫的site license。在這種環境下，再加入MySQL(或者其他的數據庫)是不明智的想法，如果DBA已經有太多環境需要處理。在存在已有數據庫的情況下，如果維護的是一個通用的平台，那麼很明顯維護的負擔會降低。進一步，如果這個公司已經有了使用某個私有系統的許可證，那麼使用MySQL的主要理由就不存在了。
產品的成熟度
通過比較，在2009年Oracle將慶祝它的第一個產品發布了30周年，那時MySQL第一個產品的發布時間還不到Oracle的一半。單就自身而言，Microsoft SQL Server僅僅比MySQL早了幾年，但是它的第一次發布的產品是基於Sybase的，該產品的比SQL Server早了6年。至於其他著名的開源數據庫，在2009年PostgreSQL距離第一次發布已經20年。雖然MySQL並不是市場上最新的數據庫，但是還有很多更老、更穩定的可選產品——並且對很多人來說，這個理由已經足夠了。公平的講，以我的觀點這個理由並不是反對使用MySQL的特別充分的理由，但是同時，我被逼著告訴一位將為關鍵任務的應用選擇平台的保守IT經理基於這個理由作決定將是錯誤的。
功能集的成熟度
有些人被吸引去編輯MySQL和其他系統的全面的功能比較，以此作為權威的決策工具，但是在很多情況下，這根本就不可能成功。隨著各個廠商新版本或者補丁的的發布，這個功能列表很快變得過時。進一步，對某些應用很重要的功能和其他的應用一點關系都沒有，這樣“10%更多的功能”將是沒有結果的度量。真正發揮作用的是在發布的時候功能集是否和需求一致，或者足夠一致。
有時候，你可以繞過一些缺少的功能，比如MySQL 4.1版本中使用join替代子查詢。RDBMS中大部分的必要的功能都在MySQL 5.0中實現，但是我們仍然有理由認為這些功能的成熟是避開MySQL的一個可能的理由。比如，缺乏視圖、觸發器和存儲過程是對MySQL由來已久的批評。這些都被MySQL支持超過一年時間了，但是相比之下，在其他的RDBMS中這些功能已經存在超過10年了。
當然，MySQL團隊的開發周期在很多方面都給人留下了深刻的印象。然而，如果用戶的性格是排斥新技術，那麼長期支持的功能獲勝的概率會更大。在這種情況下，上面提到的三個主要的功能就是最近才加入的。即使在MySQL 5.0中，ACID(Atomicity, Consistency, Isolation, Durability)的一致性在當一些存儲過程或者函數被用於修改數據庫而造成死機的情況下還是無法保證的。
認證的可用性
有一些IT公司喜歡認證。雖然MySQL的確有一個認證培訓計劃，它的培訓可用性還是沒有Oracle或者MS-SQL Server那樣廣泛。廣義上講，即使MySQL的IT人員相對容易找到，但是認證或者培訓仍然很少，也沒有很多第三方的培訓可用。對於大的IT公司而言，遵循商業數據庫系統的實際的公司經驗也是需要的，但是一些具有MySQL經驗的人可能沒有足夠的深度。
另外一個相關的問題是合格的第三方的支持的可用性。雖然直接從廠商得到的支持服務能夠在一定程度上解決這個問題，但是如果強烈的需要第三方的本地的現場支持，那麼這個問題還是存在。
公司因素的考慮
Oracle、Sybase和Microsoft都是上市公司。關於MySQL公司後台的實力的無論怎麼說，事實是這家公司不是上市公司，意味著按照法律財政數據不需要公開。冒著被指控傳播FUD(懼、惑、疑，Fear, Uncertainty and Doubt)的風險，上市公司相對透明(無論正確與否)能夠為一些IT經理和他們報告的上級提供些許的確定性、可靠性和安全。如同一句老話說的，沒有人因為購買了IBM的產品而被解雇，這句話同樣適用於這裡(即使IBM最近決定銷售MySQL);使用著名大公司的產品的確幫助一些人在晚上睡的著，他們是投資者、PHB (Dilbert reference: Pointy-Haired Bosses)和經驗豐富的IT經理。
可擴展性的領悟
我很小心的命名這最後一個理由。很多業內的專家對於MySQL不能很好的擴展都有一致的感知。這個問題被很多人都討論過，雖然大部分的討論趨於消除水平擴展和垂直擴展之間區別。MySQL談到水平擴展比垂直擴展的次數更多，但是將可擴展性列為使用MySQL的主要理由之一。
同時、我注意到存在著一個趨勢，但是我還沒有可靠的數據支持這個趨勢，那就是受過正規培訓的DBA往往會選擇私有的RDBMS，比如Oracle。我懷疑那些有正規培訓和經驗的DBA(而不是軟件工程師)往往對私有的系統有一種偏愛。在那些為DBA分配了固定角色的大環境中(相對於兼職的咨詢師或者兼具程序員身份的人)，MySQL可能由於這個原因而失寵。在這個層次上，MySQL的擴展性是否是個真實或者想象出來的批評就變的無關緊要了。如果沒有一個充分的理由顛覆這個因素，當你負責安排資源的時候，你想要給他們那些他們最喜歡、帶來好處的工具。如果你的那些具有15年經驗的DBA想要Oracle，並且Oracle也在預算之內，那麼從長遠來看這個方法會有回報的。
進行到了這裡，當比較幾種穩定的、成熟的、功能豐富的產品的時候，人們就可以不再於哪一個才是絕對意義上“更好的”產品這個問題。取代這個問題的應該是一個需要更多洞察力的問題：哪一個產品才是最適合於給定環境的。我認為主要的RDBMS產品都會遇到這個問題，包括MySQL。這個情況何時發生的問題對一些產品可能是公開的，而這幾個產品也歡迎在這個問題上展開討論。我能夠這麼說，每個產品都會有不適用的特殊時刻，這就是今天的格局，對任何主要的系統都是一樣的。在MySQL的例子中，我相信我們已經提到了幾個最充分的理由——這些理由不會是一錘子買賣，也不會很快變的過期的。
八條不使用MySQL數據庫的理由已經為大家羅列出來，上文中的內容僅供大家參考，大家在選購數據庫時可以根據自身的情況而定，最胡選擇一款適合自身發展的數據庫。
