很多公司都想要提高數(shù)據(jù)加載和查詢處理性能。在訪問了專攻數(shù)據(jù)分析、數(shù)據(jù)建模、數(shù)據(jù)倉儲和商業(yè)智能(BI)的PenguinSoft咨詢公司聯(lián)合創(chuàng)始人Mark Whitehorn先生，他表示任何一個稱職的顧問都會在提出數(shù)據(jù)倉庫改變建議之前，先看看這個公司存在的問題?？傮w上說，存儲產(chǎn)品的選擇很關(guān)鍵，有6個技巧可以改進數(shù)據(jù)庫性能。

1.在考慮性能優(yōu)化之前，需要先找出現(xiàn)存的瓶頸。如果你的查詢性能CPU負(fù)載比較高，那么買更快的磁盤就完全是浪費錢。

2.了解你的數(shù)據(jù)庫引擎。當(dāng)用戶還不了解自己數(shù)據(jù)庫輸入和輸出的時候，往往就要開始危及性能了。例如，我見過用戶使用SQL的Insert語句加載數(shù)據(jù)，而不是用更高效的批量加載工具。

我也見過用戶用delete * 來刪空一個表。這與Drop和Create相比是非常慢的，甚至比Truncate還要慢很多。當(dāng)然，也許你的數(shù)據(jù)庫軟件并不支持Truncate--這就是為什么你需要了解它是如何工作的。如果你還沒有一個好的DBA,也許單單從性能優(yōu)化的角度看就值得聘用一個。

3.就查詢而言，考慮將數(shù)據(jù)做成MOLAP立方體結(jié)構(gòu)(例如，多維在線分析處理)并事先做好聚集，這可以讓查詢性能有很大提升。雖然會占用更多的磁盤空間和數(shù)據(jù)處理時間，但在性能方面會有很大提升。

4.考慮使用固態(tài)硬盤。這對磁盤速度問題會有意想不到的成本節(jié)約。最近，我正在跟一個有35GB的OLAP Cube的客戶一起工作，性能很慢，聚集時間和查詢速度都很慢。我推薦他們試試SSD.果然，在測試工作臺上就有了一臺嶄新的70GB SSD PC.

這臺機器是配置合理，RDBMS安裝在硬盤上， OLAP cube創(chuàng)建在SSD上。Cube聚集得更快了，查詢性能的改進就更顯著了。有些查詢比相同級別的聚集快20倍。與性能的提高相比，SSD的成本是完全是微不足道的。

5.考慮在筆記本上做SSD。(我自己也這么做了，我現(xiàn)在正在用的這臺筆記本上有250G)，但這也是對磁盤集中的令人難以置信的應(yīng)用。如果可能，在內(nèi)存中執(zhí)行抽取、轉(zhuǎn)換和加載(ETL)處理。對于執(zhí)行時間很長的ETL操作，可以用磁盤緩存(以防處理失敗)，緩存到SSD而不是硬盤。

6.為分析的目的，而不是事務(wù)的目的對分析結(jié)構(gòu)做索引。聽起來很顯然，但是，我見過無數(shù)的關(guān)系型OLAP星型模式，其中的索引策略都是根據(jù)事務(wù)型系統(tǒng)的長期經(jīng)驗而做的，很少有是根據(jù)分析型系統(tǒng)的經(jīng)驗。

例如，默認(rèn)情況下，許多關(guān)系型數(shù)據(jù)庫引擎都會對表的主鍵做索引。這在事務(wù)型結(jié)構(gòu)中很普及，許多查詢都會用到這個索引--但是很少有人知道，在星型模式中，很少會用主鍵索引進行常規(guī)的單行查詢。另一方面，維表中所有的分析列都很有可能被查詢，也常常會用到索引。

【編者推薦】

1. 何為實時數(shù)據(jù)庫系統(tǒng)
2. LDAP是什么?
3. 一步一步實現(xiàn)ReportingServices2008匿名訪問
4. 淺談關(guān)系型數(shù)據(jù)庫中的壓縮技術(shù)