資料庫系統為何慢得讓人受不了？

一般而言，在應用系統安裝、上線後，其中的資料庫組態只要經過初步調校，只要所處環境的工作負載（Workload）沒有太大的改變，效能上不會出現什麼大問題，後續之所以需要進行改善效能的作業，往往是因為你的環境開始有大的異動，例如新系統上線、新的分公司成立、更多使用者加入，這時候因負載不同而需要再做調校，否則，在環境沒有大幅改變的情況下，基本上資料庫原本的配置還可以支撐很久，而不需去刻意調整。

另一種需要調整的情況則是，隨著系統上線時間越來越長，所存放的資料量日益增加，當成長到一定程度時，效能也會出現瓶頸。逸凡科技是提供Oracle資料庫顧問服務的廠商，該公司的資深技術顧問鄭樹認為現在資料庫本身所用的技術很穩定，資料庫容量只要是在500GB以下，其實問題都不大，在資料量更大的系統環境，運作上才會有一些效能潛在的問題。

然而，即使所導入的應用程式都是同一套，在每個企業、單位的實際使用狀況都是不一樣的，所能獲得的效能也有差異。鄭樹表示，首先這和所搭配伺服器可運用的資源容量（Capacity）有關，其次是人員的作業模式也不同，有的偏重在訂單處理，有的偏重事後的報表分析，這樣就會有所差異，相對地，所呈現的使用狀態也不同，因此要把很多可能影響效能的因素，都納入考量。

事實上，不單是資料庫，要管理好任何一種系統的效能，都是持續性的工作，例如半年前的狀況是正常的，而半年後不見得還是這樣，沒有絕對的定義，對於鄭樹而言，他認為最直接的方式就是看使用者的反應，例如3秒能完成一個作業，而使用者接受，這表示效能是理想的，但當使用者反應現在需要5秒才能完成，這時候你就要去看問題在哪裡，設法改善。

因為，效能是否需要調校，往往與使用者所認知到的回應時間有連帶關係，從這樣的反應來判斷，之所以是最直接也最正確的，主要是在有的作業環境中，使用者可以接受5秒回應，有的則要求一定要在3秒內，性質是不大相同的，因此回應的好壞、效能的好壞，關鍵在使用上。

管理資料庫與開發應用程式人員之間的合作與對立
要深入了解資料庫的運作狀況是否正常，許多人會先想到的是透過資料庫管理系統本身內建的功能或工具來判定，這通常需要具備資料庫專業管理知識與經驗的人才有辦法勝任。

而在大型企業環境中，通常會雇用專職的人員來擔任資料庫管理員（DBA），並由另一批人馬來負責應用程式開發，雖然各司其職看起來很理想，但對於整體系統的效能好壞，雙方都必須有一起承擔的共識。對中小企業而言，往往是程式開發人員兼任DBA，或是使用由其他軟體廠商所開發的套裝軟體，由MIS或網管人員兼任DBA，想當然耳，這些人對於資料庫功能的使用程度相對不那麼高。

在系統使用初期，通常不會有太大問題，但近年來隨著組織業務需求的快速變化，開發或導入各種應用系統的需求大增，在這過程中，後續的資料庫使用與管理上的問題，將會越來越明顯。

若是在已經配置專屬DBA和開發人員的企業環境中，面對應用系統的運作，DBA與開發人員在各自的考量下，對於系統存取的方式上，彼此的認知會產生很大的衝突，例如DBA希望確保效能，讓系統運作維持最佳運作狀態，而訂出使用的條件限制，而開發人員希望擁有最大的系統使用彈性，能不受限制地執行資料庫的存取作業，以盡快完成設計流程。

雙方考量不同會產生衝突，此外，若是在多人分工的團隊合作環境下，每個人的管理或程式設計技巧不同，所秉持的工作價值差異，也會產生相互影響、存取作業鎖定的情形，或在彼此等待對方作業完成再進行的狀況下，因為其中幾個流程步驟卡住而導致系統變慢。

若在這種工作環境下，應用程式效能出現問題，而且發現癥結是在資料庫系統上，要釐清誰該負責，以及由誰來改善，是相當困難的，有時候是DBA能發現出問題的應用程式存取，但開發人員不知道該怎麼去解決，除非有人能提供解法，否則也無法改善。

到最後僵持不下，只好透過擴充或升級伺服器硬體來解決，例如改用運算速度更快的處理器、增加記憶體容量。

對沒有雇用專任DBA的環境中，雖然負責的人自己就能做所有決定，該怎麼做不會產生意見衝突，但實際上既有IT人員並沒有太多空閒，去監督應用程式∕資料庫是否能更有效、快速地運作，因為他們通常把大部分精力和時間，花在解決提升組織業務流程效率的工作上。同時，因為他們對資料庫系統的了解更為有限，所以，當資料庫效能出問題，他們也很容易傾向先提升硬體的方式來因應。

透過變更硬體的方式看似皆大歡喜，但這只是治標，並未真正治本。就像很多人會認為，「花錢能解決的事情都是小事情，當你想花錢卻解決不了，那才是大事，」例如換一臺比原先處理速度快的設備後，而問題還是繼續存在，那才是麻煩。

抽絲剝繭，從各種層面尋找影響資料庫效能的因素
所以該用何種解法？根據市場研究機構Unisphere在2011年對Oracle產品與技術用戶的調查《Managing the Rapid Rise in Database Growth: 2011 IOUG Survey on Database Manageability》指出，因為效能問題導致停機的狀況中，最多人所選擇的是對於SQL（Structured Query Language）語法的最佳化，排名第二的是手動調整系統或資料庫組態，第三是讓搭配儲存設備的效能最佳化，第四是擴充額外的硬體伺服器或儲存設備；而對於資料庫管理而言，被認為是重大挑戰的程度中，診斷資料庫效能問題和即時辨識耗用大量資源的SQL語法，分別排名第二和第四。

SQL語法寫得不理想
應用程式執行時會需要讀取或寫入資料，因此不論是本機執行、主從式架構或多層次架構，都會需要存取檔案或資料庫，然而如果程式人員開發時若考慮得不夠周延，可能會在這裡埋下日後影響系統效能的地雷。

同樣提供資料庫顧問服務的庫柏資訊總經理林俊仁不諱言，絕大多數企業只是把資料庫當作是一個儲存空間，然而怎麼去用，很多時候他們並不會想得很透徹。Oracle亞太區MySQL技術顧問杜修文也有類似觀察，他看到有很多開發的人是用整合式開發環境（IDE）去寫程式，因此可能連資料表的索引（Index）都不會去建，或是用Schema Design（資料的結構描述設計）工具去做的，去拖拉出資料的實體關係圖（Entity-Relationship Diagram），就順便產生、建立了資料定義語言（Data Definition Language，DDL）的語法，但執行這些工作期間，他並不完全知道那代表什麼意義。

SQL語法寫得不好，若沒經過一定方式檢驗，其實不容易發現。不過隨著時代的改變，有越來越多人意識到要在系統上線前，不只是要驗證功能，還要執行壓力測試，這有助於及早發掘出未來可能發生的問題、找出解法。

若這樣的作法沒有落實、程式開發時所用的SQL語法也沒有考慮到在資料量大的環境下執行的衝擊，很可能會出現以下狀況。

在開發期間，程式人員寫好SQL語法後，往往只管所要存取的資料有沒有正確地拿到，但因為這時測試環境中的資料庫所存放的資料很少，所以即使是用最耗資源或最沒有效率的方式要求，也都可以很快連結資料庫、取得資料，等到應用程式正式上線，經過多年的使用，資料量越來越大，而原本這些SQL語法存取方式所造成的影響，就會越來越明顯。

本身是ERP軟體開發商的鼎新電腦，也提供針對微軟SQL Server資料庫相關服務，他們怎麼看待這個問題？該公司的科技系統加值暨服務事業部主任系統工程師洪智遠認為，資料庫系統效能不好，都是從每一個SQL語法所累積的，因為每個指令假如都執行得慢一點、I/O負荷多產生一些，而當整個系統有越多這樣的SQL語法在執行時，就會產生更多的負載，而這是慢慢堆疊上去的。

因此，當上線人數多到一個程度時，你就會發現系統慢到動不了，但逐一拆解時，很可能會發現，每個SQL語法其實都只是各自多耗一點點資源。洪智遠說，所以要提升效能，這必須從每一支執行的SQL語法去著手調校。

SQL寫不好，通常也和應用程式開發人員對資料庫不夠了解有關，多數人只知道用基本語法將資料取回，再用程式處理，但他們並不了解和關心對後端資料庫效能的影響和衝擊。提供資料庫監控產品的Chalet Tech公司產品經理陳仁耀在一些大學的選課系統，曾經看到類似的狀況。

當使用者透過瀏覽器連至選課系統網站，在資料庫系統上會出現大量查詢作業，陳仁耀當時看到這個系統用單筆SQL的語法，就從資料庫中查詢出5千筆或1萬筆結果，並且全部傳到前端使用者介面去。出現這樣的狀況，問題很大，因為絕對無法在同個頁面，一次顯示5千筆資料給使用者看。按理來說，每次只需要顯示一部分資料即可，例如前50筆資料，需要看到後續50筆資料時，應用系統再去資料庫查詢、取回結果。對於眼力很好的人，頂多一次看一兩百筆資料，但無論如何後續4千多筆資料都不需要在第一時間全部傳送下來、展現在前端，這等於浪費應用系統與資料庫效能，以及網路頻寬。

陳仁耀認為，這一方面是對資料庫系統的不了解，但也跟開發人員習慣把東西拿在自己手上處理、便宜行事有關。

若以每次查詢50筆資料的方式而言，當然，查詢次數越多，會出現因網路連線問題而無法將查詢結果傳送至前端的機率也會增加，但不需要的東西一直拿的狀況，在大量使用者上線操作時，問題會更明顯。例如在開學期間，選課系統的這些非必要存取，每天若重複發生幾十萬次、幾百萬次，對系統的衝擊可想而知。而在這個選課系統會出現的狀況是，當學生按下選項，系統不只是取回與自身科系有關的課程資料，而是把全校的課程資料都全部取到前端來。

若SQL寫得很複雜，對資料庫運作效能會有很大影響嗎？所要存取的資料若能因此少一點，陳仁耀覺得寧可如此，對資料庫造成的負擔會比較輕，因為資料庫的最大瓶頸通常是I/O速度。他認為如果問題出在CPU負擔重、記憶體不夠，要擴充這些並不難，但同時間內的I/O量如果太大，單靠硬體是很難處理的。

未善用資料庫系統本身提供的功能與機制
SQL語法的運用，就像一套讓應用程式進入資料庫後，提供想拿到哪些資料的標準作業程序，然而對資料庫而言，要找到這些標地物仍要費另一番功夫，你若用對方法，系統就會很快找到，相反地，你會花很多系統資源尋找，而且也要等很久時間，才能得到所要的處理結果。

事實上，資料庫裡面並不只有資料表（Table）一種形式可以去使用資料，還有檢視表（View）、索引（Index）、觸發器（Trigger）等物件。此外，還可以使用預存程序（Stored Procedure），IT人員可將較複雜的資料處理程序撰寫成程式碼，並在資料庫系統內執行，但不同資料庫系統所搭配的程式語言也有差異，例如Oracle資
料庫提供的是PL/SQL開發環境，微軟SQL Server則是T-SQL。

雖然多數資料庫作業都可以用相同的標準作法去處理，但也有些專屬的功能是必須在特定資料庫環境執行，如上述的Stored Procedure。在Oracle Database環境的Stored Procedure，就無法直接在SQL Server上面執行，反之亦然，須透過工具轉換，甚至重新撰寫，所以當你用Stored Procedure的數量越多、應用層面越深，有朝一日要更換資料庫系統平臺時，可能會需要一番功夫去轉換。

上述這樣的想法，是許多程式開發人員之所以不用這些機制的考量之一，但現在也有人提出不同的想法。

對於選擇中性、盡量不依賴任何一家廠商的技術架構、讓系統容易移植至其他平臺的考量，Oracle台灣分公司資深技術經理黃久安認為，應該是以讓應用程式發揮最大效能為前提，因為系統的運作是為了滿足使用者的需求，公司業務能藉此順利發展是更重要的價值，所以，不論所用的資料庫是哪家廠商所提供，能否盡量去發揮它的作用才是關鍵。「效能的背後，就代表Business」。

不同廠牌的資料庫系統使用上，日後要更換成其他產品，會遭遇到一定程度的困難，因為通常還是會用到各自專屬的功能，但若為了徹底發揮產品應有的功能，你還是得這麼做。長期負責SQL Server效能診斷與調校的集英信誠公司合夥顧問許致學，在他過去的經驗中，就曾經看到有用戶環境為此付出很大的代價。

故事是這樣的，這家公司因為未來可能要轉換資料庫平臺的關係，所以不允許IT人員在資料庫上用Stored Procedure，他們將所有跟資料存取相關的程序全部寫在應用程式裡，後來他們將SQL Server陸續升級了兩個版本，等於在這個平臺上用了8年，他們還是沒有將資料庫換成其他的產品，但這8年來他們用得很痛苦，因為並沒有真正發揮這套資料庫系統應該要有的效能。

對於何時會換平臺，該用戶並沒有明確計畫要在幾年後實施。許致學認為，這樣其實是拖垮效能，除非用戶確定要幾年後把資料庫平臺單一化，例如統統改成SQL Server，才有可能從現在開始不再用特定資料庫平臺的語法，以便讓未來轉換平臺時是容易的。如果不是像上面所提的那樣，而要求不能應用針對目前資料庫平臺專屬的功能，這是畫地自限，反而讓自身系統在這產品的使用上無法發揮應有的功能。

資料模式從一開始建構就出問題
資料庫的使用上，除了不夠注重與不懂SQL語法與資料庫本身機制之外，資料模式的設計是否理想，也有專家認為是可能影響效能的因素。資料模式的確立是系統開發前就必須做好的事情，但現在就像前面所提到的，應用軟體開發越來越容易，使得負責的人員輕忽了這部份的分析與設計工作。

有些企業IT人員在一開始設計資料庫的時候，在學理或技術背景不足的情況下，就開始在系統中建資料表，Embarcadero是一家提供資料庫管理與調校工具軟體的廠商，該公司的大中華區技術總監李維表示，對於真正學習過資料庫的人來說，他們所建立的資料模型，連第三正規化（Third Normal Form）的程度都沒有達到，就只是把資料庫當成資存放庫，一直將資料放進去，可是從來沒有人想到這裡所建立的模型是否正確。

一般來說，資料表建立前需經過正規化（Normalization）的程序，將其分割為獨立的小型資料表，需陸續滿足第一正規化、第二正規化、第三正規化的要求，例如資料表必須做到資料實體（Entity）範例（Instance）中都只有單一的屬性值，而且除了特定的鍵（Key）之外，屬性值不能重複。不同資料表之間，以及索引的關係，都必須用正確的模式建造出來，這樣在存取資料庫時才有效率，不會有多餘的資料與錯誤的索引。

透過該公司工具軟體的剖析，李維看到很多環境所使用的資料庫，裡面存在許多不正確的關聯、索引及多餘的資料，這些部分互相衝突，很多效能的問題就因此出現了。

資料庫效能調整前後的比較
下面的環境是在勝霖藥品公司的資料庫系統上所曾經發生的狀況。該公司使用了自行開發的資料轉換服務程式，系統會定期同步資料，結果使資料庫系統負載過高，而且這樣的狀態持續很久。後來發現問題在於字元編碼不當轉換，造成多餘的資料形態轉換作業，調整後，處理器使用率大幅降低（上圖），原本磁碟密集讀取的狀態也改善了，變得較為寬鬆（下圖）。

資料庫系統負荷在不同時段的表現有別
當應用程式以SQL語法存取資料庫中的資料時，會耗用資料庫系統的資源，並對系統造成負荷。圖中為Embarcadero的DB Optimizer軟體介面，這套產品的功能之一，是以圖形呈現資料庫狀態。

相關報導請參考「搶救資料庫效能大作戰」