今天讀了 2 篇有關資料庫效能調校的文章，希望之後能在工作上好好應用！因為手頭上一個案子常會有系統跑得很慢的問題，所以近來對“資料庫效能”的議題特別感興趣。

　　把這 2 篇文章的網址列在下面，並且整理一下節錄與心得：

1. “改善資料庫效能的關鍵作法與技術”

這篇文章主要是針對企業體提出改善資料庫效能可使用的配套方案，並介紹了幾款資料庫效能管理軟體，不管是資料庫軟體本身所提供的工具，或者是第三方廠商所開發的工具，都有大概介紹。另外對於資料庫效能調校可使用的方法（資料壓縮、分割、建立索引），也有片段講解原理與使用經驗的分享。

▌開發人員往往不知道SQL語法可以用更好的方式寫，來避免或解決資料庫效能的問題。
▌資料庫效能管理工具
▌針對緩慢的資料庫查詢作業，調校一個很久沒更新的SQL是不錯的，但查詢往往是來自應用程式的執行，因此要注意其中所使用的功能是否必要，或是系統是否有足夠的資
源，去存取這些必須被處理的大量資料。
→所以在系統查詢介面上，可以把一些可能會影響查詢效能且不常用的欄位鎖起來？所以客戶曾經主動跟我說要把一些欄位起來，算她有先見之明囉！？
▌記憶體使用效能瓶頸
▌為了未來參考之用，你也能將解決問題時所變更的部份寫成文件。
▌微軟SQL Server 2008 R2有SQL Trace、SQL Profiler，而在管理主控臺介面Management Studio上，提供多種伺服器與資料庫效能相關報表，也整合了活動監視器。到了企業版，你還可以使用資源管理員Resource Governor，利用政策來管理SQL Server工作負載和系統資源耗用量。
→不知道有沒有課程在介紹這些工具怎麼使用呢？之前公司好像有一堂課在介紹SQL Server 2008的新功能，來借上課錄影光碟看看！
▌對於SQL Server資料庫系統而言，微軟提供了所謂的遺失索引功能，可以建議管理者應該要建立，但系統目前沒有建立的索引。
→這個功能上禮拜我似乎有不巧看到，好像是把一段SQL語法使用“顯示估計執行計畫”時，會自動顯示這個小提示…
▌相較於資料庫系統廠商自己提供的軟體附加功能或工具軟體，市面上有有一些廠商，也提供管理或調校資料庫系統的工具軟體。例如Embardero的DBArtisan、DB Optimizer，Quest的Toad、SQL Optimizer。
▌當你將資料庫系統運作在合理的軟硬體環境下，所使用的SQL語法、資料庫物件也都運用得很好的狀態下，系統的效能還是非常慢，很可能是所儲存與處理的資料量已經大到一個程度了。這時候，你可以考慮採用資料庫本身提供的壓縮（Compression）和資料表分割（Partitioning）功能。
▌為什麼資料庫使用壓縮後，可以提升效能？簡單地說，是系統利用處理器的演算將資料庫中重複的部分壓縮、整合，以便讓資料佔用空間變小，如此一來磁碟I/O量也會隨之縮小。
▌微軟SQL Server，是在2008版之後開始提供資料壓縮功能，所針對的資料庫物件是資料表和索引，它分成頁面壓縮（Page Compression）和資料列壓縮（Row Compression）。
▌資料分割是將一張大資料表切割成多個資料量較小的資料表，而分割的依據，主要以常用的查詢條件來判斷，例如常用時間去查詢資料，所以我們考慮用時間這個條件來切割，之後，查詢作業就可以只針對這個部分去處理，而不用掃描整張資料表，才能找到指定資料，速度就會快很多。
▌就法規而言，有些歷史資料是必須保留的，但這些資料在目前用得很少，若把這些資料放在磁帶或其他地方，當稽核來時，可以隨時回復以便存取，在資料庫管理上，我們可以用資料分割，例如，根據月份將資料表的前6個月內容分出來，再將這些歷史資料匯出之後、從資料庫中移除，等需要因應稽核作業時，再將資料取回。這樣的作法的好處是，能在維持現有效能的情況下，又能確保資料生命週期（Information Lifecycle Management，ILM） 的部份被管理到。
→ 歷史資料庫的製作？
▌頁面壓縮因為是整個頁面壓縮，適用在當下比較不會存取到的歷史資料，而資料列壓縮是一筆一筆資料壓縮，比較適合現行資料。如果以相反的方式配置，原本預期想要透過壓縮來提升效能的效果，可能會大打折扣。例如將現行資料以頁面壓縮方式處理，因為經常需要讀寫，因為會經歷整個頁面解壓縮、讀取、寫入、再壓縮至整個頁面的過程，所以反而會增加不少I/O量。
▌索引並非用得越多，效能就越好。因為索引建立後，會在磁碟空間上有實際存在的資料──比如把地區別當成索引，資料庫系統就會把地區別的資料，寫一份在磁碟上，之後資料有異動時，系統會需要維護這個索引的內容，所以索引的使用不只是會占額外空間，而且是需要維護的。因此，當索引建立得太多，資料庫的寫入效能就會受到嚴重影響。簡而言之，索引的建立，必須要按照資料使用的特性、該環境的使用習慣去考量。
→某客戶資料庫的某個table實在太誇張了…也有可能是索引建立太多導致資料庫寫入效能受到影響吧！不過…要怎麼維護索引呢？
→ 讀完這篇文章後，針對該客戶提出以下的解決方式：
1. 建立歷史資料表機制。
2. 針對歷史資料表做頁面壓縮。
3. 流程相關資料表使用資料列壓縮。
4. 詳細思考各 table 的 index 建立是不是有其必要。


2. “淺談 Index Seek 和 Scan”

學會使用 “顯示估計執行計畫”功能後，就對其分析結果所顯示的“資料表掃描”、“索引搜尋”、“叢集索引搜尋”…等字眼感到很好奇，不曉得各代表什麼含意。這篇文章可以說有釐清了我的一些疑惑。不過，如果要更加有所體悟，變更索引組合試驗是不錯的方法。

▌Seek 只有在建 Index 後才會有可能發生，並且建了 Index 後，系統可不一定就會用 Seek 的方式查找資料！
→若沒有建立 Index，就不會 Seek 通通都用 Scan 的。文章說即使建立 Index 也不一定會用 Seek 的方式搜尋資料，這我也有經驗過，且還蠻困惑的，當時就覺得應該是跟 Index 與 where 條件組合有關。