18岁以下禁看网站,精产国品一二二区入口,日本老头老太XING交,超强C程序,车辆颠簸就滑进逼里小说

Oracle一個CPU核心的許可證賣47500美元。一臺普通的雙路16核服務器，光數據庫軟件就要152萬美元，每年還有22%的維保費。

MySQL免費。

這兩個東西居然是同一個公司（Oracle Corporation）的產品。而且論裝機量，MySQL比Oracle多得多——全球互聯網公司幾乎清一色在用它。

一個賣天價，一個白送，它們到底差在哪？SQL Server又憑什么在中間活得好好的？

裝一遍就知道了

你裝MySQL，下載一個壓縮包解壓，改個配置文件，mysqld --initialize 然后 mysqld &，完事。整個過程可能不到五分鐘。MySQL就是一個進程，幾十兆內存就能跑起來。

你裝Oracle，光看安裝文檔就要半小時。Oracle是一組進程群——啟動之后你用 ps 看，會發現一堆后臺進程同時在跑：DBWR在刷臟頁、LGWR在寫redo日志、PMON在回收死連接、SMON在做實例恢復、CKPT在觸發檢查點。每來一個客戶端連接，Oracle還要fork一個專用服務進程伺候它。

# Oracle 啟動后的進程列表（簡化）
ora_pmon_ORCL
ora_smon_ORCL
ora_dbw0_ORCL
ora_lgwr_ORCL
ora_ckpt_ORCL
# ... 還有一堆

一臺機器上跑十個MySQL實例很正常。跑十個Oracle實例？你的服務器可能先躺了。

這不是缺陷，是設計取舍。Oracle每個進程獨立運行，一個掛了不影響別的，隔離性拉滿。MySQL所有連接共用一個進程里的線程，輕量，但一個線程搞崩了理論上能把整個mysqld帶走。

SQL Server也是多線程，但它搞了個狠活——自己寫了一套線程調度器叫SQLOS，不用操作系統的調度。線程什么時候讓出CPU，SQLOS說了算。好處是調度策略可以針對數據庫場景深度優化，壞處是某個線程卡死不讓出CPU的話，整個調度都堵了。

所以Oracle的部署形態就是"一臺大機器專門跑一個數據庫"。MySQL反過來，資源占用少，啟動快，天然適合云和容器化，一臺機器上塞好幾個實例也不心疼。

Oracle憑什么賣那么貴

Oracle貴，但你確實能看到錢花在哪了。

RAC（Real Application Clusters）。 多臺服務器各自跑一個Oracle實例，但共享同一份存儲上的數據庫。一個節點掛了，其他節點還在跑，業務幾乎無感知。MySQL的主從復制？主庫掛了你得等從庫追完binlog才能切，這中間的幾秒到幾十秒，對銀行來說就是事故。

Data Guard。 容災方案。主庫在北京，備庫在上海，redo log實時同步。北京機房出事了，上海可以接管。MySQL也能搞類似的架構，但你得自己拿一堆社區工具拼——Orchestrator做切換、ProxySQL做流量轉發、GTID做復制定位——出了問題沒人兜底。

閃回技術。 有人誤刪了一張表的數據。MySQL呢？祈禱你有binlog，然后寫個腳本從binlog里把數據撈回來。Oracle？一條命令：

FLASHBACK TABLE orders TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' HOUR);

一小時前的數據直接回來了。

銀行不怕數據庫慢一點，怕的是丟數據、怕的是業務中斷。RAC、Data Guard、閃回，全是在解決"出了事怎么辦"的問題。Oracle賣的不是性能，是安全感——出了問題可以開SR（Service Request），Oracle的工程師遠程幫你查。

MySQL出了問題你去哪找人？Stack Overflow發帖等回復？

免費的MySQL怎么打贏的

MySQL走的是完全不同的路——單機能力不跟Oracle比，靠數量堆上去。

互聯網公司的數據庫實例動輒幾千臺。阿里巴巴內部的MySQL實例數量是六位數級別的。按Oracle的價格算，一年光許可證就要花幾個億——這筆錢夠養一個幾百人的DBA團隊自己搞了。

實際上這就是互聯網公司的選擇：用免費的MySQL，養自己的數據庫團隊來搞定高可用、分庫分表、備份恢復。阿里搞出了AliSQL，騰訊搞出了TXSQL，美團也有自己的MySQL分支。大公司有能力自己改內核，不需要Oracle的原廠支持。

MySQL還有個Oracle沒有的優勢：可插拔存儲引擎。MySQL的架構分成Server層和存儲引擎層，中間用Handler API連接。默認的InnoDB處理事務型業務，Facebook搞了個MyRocks用LSM樹優化寫入密集場景。Oracle和SQL Server的存儲引擎是焊死的，你用也得用，不用也得用。

不過這個"優勢"也留下了歷史包袱。MySQL有兩套日志——Server層的binlog和InnoDB的redo log，兩套日志之間要用兩階段提交來保證一致性。Oracle只有一套redo + undo，沒這個問題。

MySQL崩潰恢復的時候要同時對比binlog和redo log才能判斷事務是不是真的提交了——架構分層的代價。

SQL Server在悶聲發財

技術社區里提到數據庫，基本就是MySQL、PostgreSQL、Oracle輪著聊。SQL Server？偶爾被提一嘴，通常是"那個只能跑在Windows上的"。

但實際裝機量完全是另一回事。全國大量的制造業ERP、醫院HIS系統、政務OA、零售POS系統跑的都是SQL Server。這些系統的開發者不在技術社區發聲，但它們每天處理的是真金白銀的業務數據。

SQL Server能在這些場景站穩，說白了就是省心。

它的管理工具SSMS（SQL Server Management Studio）是真的好用。可視化建表、拖拽式備份還原、圖形化的執行計劃分析、內置的性能調優顧問——一個普通的IT運維，看幾天文檔就能把數據庫管起來。

MySQL呢？一堆參數要調，高可用要自己搭，備份恢復要寫腳本。Oracle呢？先花三個月學完OCA的課程再說。

SQL Server加上Windows Server加上.NET，一套微軟技術棧從操作系統到數據庫到應用層全包了。出了問題一個微軟的support電話就行。IT預算有限、沒有專職DBA的中小企業，很難抗拒這種"全家桶"。

MySQL遷到SQL Server，上線就炸

如果你從MySQL遷移到SQL Server（或者反過來），有一個坑是一定會踩的。

MySQL的InnoDB默認就開了MVCC——讀寫不互相阻塞，SELECT不會被UPDATE擋住，這是天然的。

SQL Server的默認行為不是這樣。它的READ COMMITTED隔離級別默認用的是鎖，不是MVCC。一個UPDATE沒提交，所有讀同一行的SELECT全部阻塞等著。

-- SQL Server：不開這個，讀寫就會互相阻塞
ALTER DATABASE MyDB SET READ_COMMITTED_SNAPSHOT ON;

很多從MySQL遷過來的團隊一上線就發現"怎么數據庫這么慢"，查了半天才發現是讀寫互相阻塞。

反過來也有坑。從SQL Server遷到MySQL的團隊偶爾會發現——MySQL的REPEATABLE READ下居然不會出現幻讀（InnoDB用了間隙鎖），SQL Server在同樣的隔離級別下是會的。

同一個SQL標準，三種數據庫三種行為。

UUID做主鍵，MySQL和Oracle差了十倍

實際開發里還有一個經常引發困惑的差異。

InnoDB的表數據是按主鍵組織成B+樹存儲的，葉子節點直接存完整的行數據。用自增整數做主鍵，數據順序寫入，很快。用UUID做主鍵，36個字符長（varchar存儲）、隨機分布，每次插入都可能要往B+樹的中間塞數據，頻繁觸發頁分裂，性能會差很多。

Oracle不一樣。Oracle默認用堆表——數據按插入順序往后堆，主鍵只是個約束，不影響物理存儲。所以Oracle用UUID做主鍵完全沒問題。

SQL Server和InnoDB類似，默認也會按主鍵建聚集索引。但SQL Server靈活一些——你可以選擇不建聚集索引，也可以在非主鍵列上建。

這個差異在MySQL開發者跳到Oracle團隊、或者Oracle開發者接手MySQL項目的時候經常引發困惑。MySQL開發者到了Oracle組發現"怎么主鍵用varchar都沒事"，Oracle開發者接了MySQL項目發現"怎么換個主鍵類型性能差了十倍"。

寫CRUD的時候三個數據庫幾乎沒區別，踩到架構層的差異才會懵。不過InnoDB的Buffer Pool對應Oracle的SGA Buffer Cache，redo log對redo log，undo log對undo tablespace——概念全是對應的，搞透一個，另外兩個上手很快。