甲骨文(Oracle)迎娶昇陽(Sun)後，是否宣告MySQL就此消失，是許多MySQL使用者與企業關切的重要議題。我試著從甲骨文的購併史與MySQL的市場狀況等2個構面，來回應這個問題：
甲骨文向來善於從購併來的公司中發現好產品。此話怎說？讓我們先一起來回顧甲骨文是如何處理購併來的產品服務：
第一，BEA購併案：扶持優秀產品。
購併BEA後，甲骨文大刀闊斧的以BEA的Java Container–WebLogic，取代自身的Java Containers–OC4J(Oracle Containers for J2EE)：甲骨文的中介軟體（Fusion Middleware；FMW）產品改以BEA的WebLogic為核心。甲骨文會這麼做，主要是因為WebLogic的效能比OC4J佳。
而且還開始支持、銷售BEA的其它產品，以Portal為例，甲骨文自己雖然也有Portal產品，但在購併BEA後，我們開始在甲骨文中介軟體(FWM)這條產品線中，看到BEA的WebLogic Portal(WLP)蹤影；除此之外，甲骨文的經銷伙伴在銷售Portal產品時，也轉以WebLogic Portal(WLP)為主。
第二，Siebel購併案：挖掘好的產品。
我想討論的不是Seibel的顧客關係管理(CRM)軟體，而是Seibel顧客關係管理軟體內建的商業智慧引擎。Siebel被併購後，除Siebel顧客關係管理軟體躍為甲骨文的顧客關係管理軟體的主流產品外，顧客關係管理軟體裡的商業智慧引擎也被挖掘、發展成甲骨文主力推廣的商業智慧產品：商業智慧企業版（Business Intelligence Enterprise Edition；BIEE）。
至於甲骨文原生的商業智慧產品─Oracle Discovery，則退居為二線產品：商業智慧標準版（Business Intelligence Standard Edition；BISE）。
隨著甲骨文的產品策略調整，甲骨文的經銷合作夥伴也漸漸不再銷售甲骨文的原生商業智慧產品─Oracle Discovery，也就是現在的商業智慧標準版(BISE)；關於這點，我其實挺訝異的，畢竟，甲骨文當初看中的是Seibel的顧客關係管理(CRM)軟體，沒想到，最後竟然連顧客關係管理軟體的元件─商業智慧引擎，也一併用上了，而且還拔擢成一線產品。
在實際比較、試用過商業智慧企業版(BIEE)與商業智慧標準版(BISE)等兩套產品後，我認為甲骨文的策略是對的，也佩服其細心與遠見；畢竟，就系統成熟度來說，Siebel的商業智慧引擎的遠高於甲骨文原來的商業智慧工具。
第三，Hyperion購併案：留下、發展有價產品。
在甲骨文挖掘Siebel顧客關係管理軟體的商業智慧引擎成為商業智慧的主力產品後，市場對於其會如何整併購併進來的Hyperion、重劃商業智慧產品線，十分關注。
會宣告商業智慧企業版(BIEE)結束營業、改以Hyperion為商業智慧工具的一線產品嗎？如是依照以往的經驗，Hyperion確實可能憑藉既有市佔、完全取代甲骨文的商業智慧企業版(BIEE)，畢竟，商業智慧企業版(BIEE)只是從Seibel顧客關係管理軟體的一個元件發展出來，而且，商業智慧企業版(BIEE)的市佔，也不可能(短期內)一下子就衝得跟Hyperion一般。
但是，很特別的，甲骨文把商業智慧企業版(BIEE)留下來了，而且還加進了Hyperion IR與 Hyperion Essbase的某些功能，推出新的商業智慧工具─BIEE Plus。
至於Hyperion的其他產品，如企業績效管理(Enterprise Performance Management；EPM)，甲骨文則為其在中介軟體(FMW)這條產品線中找到定位：在商業智慧分析的金融等專業應用領域中，成為甲骨文的主力產品。
從上述三個購併案來看，甲骨文對於被整併公司的產品態度，並不單純以本家/外來者、或者是以市佔率作為優先考量，產品本身的可用性、技術性、整合性，以及發展性，才是左右其產品決策的核心。也因如此，我認為，只要是夠成熟、有其技術或發展價值的產品，就算它是外來品，仍有機會在甲骨文的產品線中，嶄露頭角。
市場（使用者）有權決定MySQL的存續
MySQL之於甲骨文的狀況，其實有點像Sparc/Solaris之於IBM的情況。
開放原始碼這個特性已保障了MySQL的存續。決定MySQL能否繼續存在這個市場的人，是熱愛使用開源碼的廣大使用者以及開發者，而不是甲骨文。
也就是說，就算甲骨文這個大當家對MySQL的態度是存而不論，難道MySQL(非甲骨文)的開發者就不能持續地開發、維護它嗎？
換個方向想，就算甲骨文決定以目前的版本為基礎，開發一個新的、需要付費的MySQL版本，難道開源碼體制下的MySQL愛好者、開發者不能基於既有的MySQL版本開發另一套依舊免費(Free)的MySQL嗎？(版本、名稱必須與既有版本做區格，以免出現混淆或者是侵權）
講難聽一點，甲骨文只買得走MySQL這個名字、無法獨霸MySQL的源碼(Source Code)。理由也很簡單─MySQL的源碼已經開放(Open）很久了；所以，最差的情況是，開發人員以這些被開放(Open)出來的MySQL源碼為基礎、稍做改良，並且改個名字（看是要叫nonOracleSQL、DuncanSQL、或ShowSQL都可）後，就可以重新再出發了。
說不定，在甲骨文宣布購併昇陽的同時，已有MySQL的忠實愛好者、或支持MySQL的開發者已在這麼做了。
另外，甲骨文也不是第一次涉入Open Source的軟體；至少在前(2007) 年，其就透過Unbreakable Linux計劃跨足Linux服務市場了，可你猜怎麼著？紅帽(Red hat)、FreeBSD或其它的Linux廠商並沒有因為甲骨文宣佈加入該市場而消失。
MySQL亦然；從某個角度來看，甲骨文只不過是廣大MySQL開發者的一份子，MySQL存活與否，是由市場供需（需：有人要使用；供：有人進行維護)決定，而不是甲骨文說了算。
再者，以MySQL的市場使用率來說(這邊必須再次強調，我說的不是資料儲存量)，其極可能是資料庫市場之冠，畢竟，有太多開發人員、微型與中小型企業喜愛、使用MySQL這個免費又開放的資料庫產品。在這樣的狀況下，換做我是甲骨文，即便MySQL沒辦法為我賺錢，我至少還是可以利用MySQL賺個「名」。
持平而論，Solaris以及其它的硬體才是甲骨文垂涎之處，MySQL反倒不是重點，在這樣的狀況下，我個人認為，短期內，甲骨文對MySQL的態度比較可能是：存而不論。
但這又如何呢？支持MySQL的開發者、企業還是可在開源碼的規劃下使用、維護與開發它，不論現在或未來，甚至是將之換個名字再出發；那甲骨文若決定加入MySQL的開發與維護市場？那我們又為何不能採以開源碼(Open Source)中的開放(Open)胸襟，擁抱、歡迎他的加入呢？