第一步，優化字段
原始數據導入數據時，對所有字段進行優化，儘可能地爲每個字段選用最小的字段類型
字符型字段，一般導入時默認會是nvarchar型，改爲varchar型節省一半空間。
數值型字段，如果是整數，如果最大可能數小於255，改爲tinyiny，如果最大可能數小於32768，改爲smallint，如果長度小於9位，改爲int。如果帶小數點，精度要求不是非常高的話，改爲real。
日期型字段，如果只需要精確到天的話，改爲date型
這樣經過優化之後，該數據所佔的文件尺寸常常能縮小一倍左右。數據查詢的性能會得到一定的提升。
第二步，橫向拆分表
按照關係數據庫三範式的原則，對原始的數據表進行拆分。一張原始表，一般能拆解成分散開來的十幾張表。通常來說，拆解後的表，會有一張核心的“事實表”，和多張“維度表”組成。
大多少情況下說，適當拆表後，這張核心的“事實表”，只會剩下很少的幾個字段（列），但行數會很多，幾千萬或上億行。而其它的“維度表”，則是字段（列）很多但行相對很少。
舉 一個例子，比如說原始的數據表中，有Year,Quarter,Month,Week,Date五個字段，那麼實際上我們只需要保留Date這個字段在核
心的“事實表”表內即可，其它的Year，Quarter等字段可以通過拆分出來的日曆表（“維度表”），在需要的時候再匹配回來。
經過這第二步優化後，該數據所佔的文件尺寸一般能在前面第一步的基礎上，再縮小數倍
縱向拆分表
在數據量巨大，同時可以按年或季度劃分數據時，將上一步分好的核心“事實表”，再按不同的年份或季度拆分成各個分開的表，能進一步提高數據分析時的查詢速度。
縱向拆分出來的表，表結構完全相同，只是用不同的表名存不同年份或季度的數據。
不用擔心後期分析時麻煩，後期分析時可以用視圖再把這些表連在一起，所以最後分析數據時，不管前面的步驟拆了多少張表，最後只需要連接使用單獨的一張最終視圖就可以。
建立索引
對應所有的表，都應該儘可能的建立主鍵。
建立主鍵的第一個好處是，它可以提高“事實表”和“維度表”查詢時的關聯速度，也就是提高最後進行分析運算時的查詢速度。
建立主鍵的第二個好處是，它可以預防導入重複的數據，保證數據的正確性。
對應有可能經常被用做查詢時作爲過濾篩選條件的字段，應儘可能都建立索引。但索引會佔據額外的磁盤空間，同時降低寫入新數據和修改數據的速度，所以索引字段也不宜太多。對於以查詢爲主的表，可以多建一些索引，但對於會大量實時修改的表，則不宜有太多的索引字段。
這第四步的優化，可以使得在後面分析查詢時，數據篩選的效率翻倍的提高。
恰當的硬件
其實CPU不太重要，如果任何時候如果你在跑SQL數據查詢時發現你CPU負荷100%滿了，那一定是你的查詢代碼寫錯了。
下面兩個部件，可以提升數據查詢的速度：
第一是內存，能配多大配多大。如果是32Bit的操作系統的話，配到4GB內存（再多的部分32Bit的OS認不了），如果是64Bit的OS的話，配到你主板能支持的極限。（記得打開MS
SQL的AWE內存分配功能）
第二是硬盤，簡單的說，配個SSD硬盤能讓你的SQL速度倍增。
另外記得再多買個硬盤備份，不然數據沒了沒處哭去的……
正確的查詢語句
簡單地說，就是在寫查詢語句時，要寫成像卷心菜一樣一層一層往外逐步過濾匹配數據。不要寫成一棵大樹一樣一口氣試圖關聯所有數據進行匹配計算，那樣笛卡爾乘效果形成的數據膨脹，能讓你的SQL跑上半天也不理睬你。（CPU 100%負荷就是這麼出來的）
摘录于:http://www.zhihu.com/question/20756848
原文地址：http://www.cnblogs.com/mk9007/p/3745866.html
