還記得好康妹的工商服務好文推廣時段嗎？
許久不見的新文章隨著新年新氣象來囉～
到底各位大大心目中的資料庫第一名是什麼呢？會比較哪些項目啊？

回顧系列前文：
【好文分享】迷思止步！資料庫應用大無限－SQL Server 其實不簡單！
【好文分享】迷思止步！資料庫應用大無限－Big Data 掏金就得砸大錢蓋礦場
【好文分享】關鍵資料庫太「關鍵」，豈能以不變應萬變?
◆迷思止步 資料庫應用大無限！
資料庫效能，究竟有無第一名？

在DBA心目中，對於各廠牌資料之間的效能高下，往往擁有一番定見；總是有若干人認為，某些供應商從資料庫起家，肯定是這個領域的第一把交椅，在效能部分穩居盟主寶座；然而這般見解，究竟是顛撲不破的真理？還是摻雜了幾許謬誤？讓我們繼續看下去！

絕大多數的企業應用系統，都會隨著時間演進，因而累積大量資料，這些資料都需要被整理為有用資訊，才可成為彌足珍貴的數位資產；在此情況下，賴以管理大量資料的資料庫系統，確實是企業資訊之命脈，除須擁有不容閃失的高穩定度外，當然也應該擁有優異的運作效能。

因此，多數DBA都不會懷疑，懂得選擇一套高效能的資料庫，絕對是他們職涯當中重要的必修學分，否則萬一挑到效能不彰的系統，導致企業應用服務無法流暢運行，進而惹得公司從上到下怨聲載道，這個罪名對於DBA來說，無疑是不可承受之重。

儘管市場上資料庫品牌為數不多，但要想評斷它們孰優孰劣，似乎也沒那麼容易。因為資料庫效能測量環境，需要在相同的商用負載執行情境下，動用時間、人力、財力、能力等可觀資源堆砌而成，而且不論是壓力測試或單元測試，其過程都務求擬真徹底，任何環節都不容疏漏，如此才能確保測試結果的精準度；這一切的一切，顯然並非輕而易舉之事。

既然執行測試大不易，部分DBA寧可選擇抄捷徑，聽取幾個前輩與同業的意見，就這麼演化出一套似是而非的邏輯，未經詳細驗證，直接就認定某某品牌資料庫為首選，心想反正有人強力推薦，其效能勢必出類拔萃，用了準沒錯。

殊不知別人用得虎虎生風的系統，到了自己的環境，卻未必盡如人意；DBA這才有所頓悟，下回面臨資料庫品牌的抉擇之際，還是得老老實實走完概念驗證(POC)程序，眼見為憑最重要，不要繼續人云亦云。

表面看來，這個遲來的頓悟似乎有理，但倘若主其事的DBA依舊思路閉塞，未能釐清一些基本課題，縱使做足了POC，恐怕也未必能覓得最佳資料庫。

評估資料庫效能，需隨情境而調整
不可否認，在若干DBA的印象中，提到效能評價，部分執行於UNIX環境的資料庫品牌，始終凌駕於SQL Server之上，殊不知近期一些用戶端系統的資料庫測試比較，SQL Server反而是輸少贏多的；關鍵除在於SQL Server效能的持續提升外，另透過SQL Server的記憶體優化技術xVelocity 大幅提升查詢效能，針對大量交易系統則採用Snapshot Isolation隔離層級有效降低Block的發生，更搭配分割資料表卓越功能，以致讓SQL Server在各大戰役中無往不利。

值得一提的，SQL Server 2012內建Distributed Replay功能，可有效模擬大量資料對SQL Server進行壓測，無需購買昂貴軟體，亦使SQL Server在校能或性價比上大幅超越對手。SQL Server憑藉友善與完整的管理工具，搭配相對容易取得的專業諮詢服務，即不難被調校出優異狀態，反觀其餘資料庫系統，除了效能有待商榷外，DBA意欲覓得正確資源，將之調校出應有表現，本身即是一大挑戰。

資料庫技術發展數十載，相關技術已經相當成熟，倘若不同廠牌系統並肩而坐，各方皆在相同情境標準的設定下，再佐以應有的專業調優設定，有些時候確實會出現效能難分軒輊的場景，只因眾家系統所運用的資料存取方式與技術，相似度極高，影響所及，彼此之間性能好壞之差別，也可能不甚明顯；換言之，不論是特定資料庫系統長期被人奉為上上之選，抑或 SQL Server 曾被誤解為效能有待加強，說穿了，全都是偽命題，與實情並不吻合。

所有商用資料庫一字排開，SQL Server的效能表現鮮少居於劣勢，優異的表現亦是備受肯定。既然環顧各家資料庫的處理效能，SQL Server始終名列前茅，所以在客觀條件相同的前提下，DBA的評選標準就很簡單，何者的總體持有成本(TCO)最低，便是不二選項，因為就算費盡心力追逐高價系統，也無法換取更佳效能。

效能疲軟，未必是資料庫闖的禍
不可否認，雖然眾家資料庫體質雷同，但只要分別被投放到不同應用環境，實際效能表現總是天差地遠，有的健步如飛，有的卻步履蹣跚；但即使發生後者現象，難道就可對該資料庫系統大加撻伐？非也！絕大多數情況下，原因並不在於系統先天不良，而是其他後天不良因素惹的禍。

如同前述，各資料庫賴以讀寫資料的方法，其實都很類似，因此它們所面臨的效能瓶頸，自然如出一轍，都很容易受限於伺服器、儲存設備或SAN交換器等硬體I/O，所以在大多數情況下，或許僅須將硬體更換為優規設備，就能化解效能疲弱之病態。

只不過，有時換了機器，資料庫運行速度卻未見提升，其癥結顯然就不在I/O瓶頸之上，可能源自於低效的查詢，或是應用程式本身的設計不良；值此時刻，DBA即應保持淡定，先以抽絲剝繭方式找出問題根源，再將練就多時的調優技巧施展開來，看看是要將資料庫的邏輯加以正規化，改採更具效率的索引設計與查詢設計，或是設法分解並隔離慢速的SQL查詢，總之用盡一切的力量，將惱人的效能問題加以革除。