一：常見的題目：
1. 給你A,B兩個檔案，各存放50億條URL，每條URL佔用64位元組，記憶體限制是4G，讓你找出A,B檔案共同的URL。
2. 有10個檔案，每個檔案1G， 每個檔案的每一行都存放的是使用者的query，每個檔案的query都可能重複。要你按照query的頻度排序
3. 有一個1G大小的一個檔案，裡面每一行是一個詞，詞的大小不超過16個位元組，記憶體限制大小是1M。返回頻數最高的100個詞
4. 海量日誌資料，提取出某日訪問百度次數最多的那個IP。
5. 2.5億個整數中找出不重複的整數，記憶體空間不足以容納這2.5億個整數。
6. 海量資料分佈在100臺電腦中，想個辦法高效統計出這批資料的TOP10。
7. 怎麼在海量資料中找出重複次數最多的一個
8. 上千萬or億資料（有重複），統計其中出現次數最多的前N個數據。 統計可以用hash,二叉數,trie樹。對統計結果用堆求出現的前n大資料。增加點限制可以提高效率，比如 出現次數>資料總數／N的一定是在前N個之內
9.  1000萬字符串，其中有些是相同的(重複),需要把重複的全部去掉，保留沒有重複的字串。請問怎麼設計和實現？
10. 一個文字檔案，大約有一萬行，每行一個詞，要求統計出其中最頻繁出現的前十個詞。請給出思想，給時間複雜度分析。
11. 一個文字檔案，也是找出前十個最經常出現的詞，但這次檔案比較長，說是上億行或者十億行，總之無法一次讀入記憶體，問最優解。
12. 有10個檔案，每個檔案1G， 每個檔案的每一行都存放的是使用者的query，每個檔案的query都可能重複要按照query的頻度排序
13. 100w個數中找最大的前100個數
14. 尋找熱門查詢：
搜尋引擎會通過日誌檔案把使用者每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度為1-255位元組。假設目前有一千萬個記錄，
這些查詢串的重複度比較高，雖然總數是1千萬，但如果除去重複後，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的使用者越多，
也就是越熱門。請你統計最熱門的10個查詢串，要求使用的記憶體不能超過1G。
（1）請描述你解決這個問題的思路；
（2）請給出主要的處理流程，演算法，以及演算法的複雜度。
15. 一共有N個機器，每個機器上有N個數。每個機器最多存O(N)個數並對它們操作。
如何找到N^2個數的中數(median)？

二：原因所在：
1）資料量過大，資料中什麼情況都可能存在。如果說有10條資料，那麼大不了每條逐一檢查，人為處理，如果有上百條資料，也可以考慮，如果資料上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或者程式進行處理，在海量的資料中，什麼情況都可能存在，例如，資料中某處格式出了問題。尤其在程式處理時，前面還能正常處理，突然到了某個地方問題出現了，程式終止了。
2) 軟硬體要求高，系統資源佔用率高。對海量的資料進行處理，除了好的方法，最重要的就是合理的使用工具，合理分配系統資源。一般情況、如果處理的資料過TB級，小型機是要考慮的，普通的機子如果有好的方法可以考慮，不過也必須加大CPU的記憶體，就象面對著千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。
3) 要求很高的處理方法和技巧。

三：優化總結：
1）資料庫選擇：
現在的資料庫工具廠家比較多，對海量資料的處理對所使用的資料庫工具要求比較高，一般使用Oracle或者DB2，微軟的SQL Server2005效能也不錯。另外在BI領域：資料庫，資料倉庫，多維資料庫，資料探勘等相關工具也要進行選擇，象好的ELT工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實際資料分析專案中，對每天6000萬條的日誌資料進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005則只需要花費3小時。
2）程式碼優化：
處理資料離不開優秀的程式程式碼，尤其在進行復雜資料處理時，必須使用程式。好的程式程式碼對資料的處理至關重要，這不僅僅是資料處理準確度的問題，更是資料處理效率的問題。良好的程式程式碼應該包含好的演算法，處理流程、效率和異常處理機制等。
3）海量資料分割槽操作
對海量資料進行分割槽操作十分必要，例如針對按年份存取的資料，我們可以按年進行分割槽，不同的資料有不同的分割槽方式，不過處理機制大體相同。例如SQL Server的資料庫分割槽時將不同的資料存於不同的檔案組下，而不同的檔案組存於不同的磁碟分割槽下，這樣將資料分散開，減少磁碟I/O，減少系統負荷，而且還可以將日誌、索引等放於不同的分割槽下。
4）建立廣泛的索引：
對海量的資料處理，對大表建立索引是必行的。建立索引要考慮到具體情況，例如針對大表的分組、排序等欄位，都要建立相應索引，還可以建立複合索引，對經常插入的表則建立索引要小心，筆者在處理資料時曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集，非聚集索引都要考慮。
5）建立快取機制：
當資料量增加時，一般的處理工具都要考慮到快取問題，快取大小設定的好差也關係到資料處理的成敗，例如，筆者在處理2億條資料聚合操作時，快取設定為100000條/Buffer，這對於這個級別的資料量是可行的。
6）加大虛擬記憶體：
如果系統資源有限，記憶體提示不足，則可以靠增加虛擬記憶體來解決。筆者在實際專案中曾經遇到針對18億條的資料進行處理，記憶體為1GB1個P4 2.4G的CPU，對這麼大的資料量進行聚合操作是有問題的，提示記憶體不足，筆者採用了加大虛擬記憶體的方式來解決，在6塊磁碟分割槽上分別建立了6個4096M的磁碟分割槽，用於虛擬記憶體，這樣虛擬記憶體則增加為4096*6+1024=25600 M，解決了資料處理中的記憶體不足問題。
7）分批處理：
海量資料處理難因數量大，那麼解決海量資料處理難的問題其中一個技巧是減少資料量。可以對海量資料分批處理，然後處理後的資料再進行合併操作，這樣逐個擊破，有利於小資料量的處理，不至於面對大數量帶來的問題，不過這種方法也要因時因勢進行，如果不允許需要拆分資料，還需要另想辦法。不過一般的資料按天、按月、按年等儲存的，都可以採用先分後合的方法，對資料進行分開處理。
８）使用臨時表和中間表：
資料量增加時，處理中要考慮提前彙總。這樣做的目的是化整為零，大表變小表，分塊處理完成後，再利用一定的規則進行合併，處理過程的臨時表的使用和中間結果的儲存都非常重要，如果對於超海量的資料，大表處理不了，只能拆分為多個小表。如果處理過程中需要多步彙總操作，可按彙總步驟一步步來，不要一條語句完成一口氣吃掉一個胖子。
９）優化ＳＱＬ語句：
對海量資料進行查詢處理過程中，查詢的SQL語句的效能對查詢效率的影響是非常大的，編寫高效優良的SQL指令碼和儲存過程是資料庫工作人員的職責，也是檢驗資料庫工作人員水平的一個標準，在對SQL語句的編寫過程中例如減少關聯，少用或不用遊標，設計好高效的資料庫表結構等都十分必要。筆者在工作中試著對1億行的資料使用遊標，進行3小時沒有出結果，這時一定要改用程式處理了
10）使用文字格式進行處理：
對一般的資料處理可以使用資料庫，如果對複雜的資料處理，必須藉助程式，那麼在程式操作資料庫和程式操作文字之間選擇，是一定要選擇程式操作文字的，原因為：程式操作文字速度快；對文字進行處理不容易出錯；文字的儲存不受限制等。例如一般的海量的網路日誌都是文字格式或者csv格式（文字格式），對它進行處理牽扯到資料清洗，是要利用程式進行處理的，而不建議匯入資料庫在做清洗。
11）定製強大的清晰規則和出錯處理規則：          
海量資料中存在著不一致性，極有可能出現某處的瑕疵。例如同樣的資料中的時間欄位，有的可能為非標準的時間，出現的原因肯能是應用程式的錯誤，系統的錯誤等，這是在進行資料處理時，必須制定強大的資料清洗規則和出錯處理機構。
12）建立檢視或者物化檢視：
檢視中的資料來源於基表，對海量資料的處理，可以將資料按一定的規劃分散到各個基表中，查詢或處理過程中可以基於檢視進行，這樣分散了磁碟I/O，正如10根繩子吊著一根柱子和一根繩子吊著一根柱子的區別。
13）避免使用32位機
目前的計算機很多都是32位，那麼編寫的程式對記憶體的需要便受限制，而很多的海量資料處理是必須大量消耗記憶體的，這便要求更好效能的機器，其中對位數的限制也十分重要。
14）使用資料倉庫和多維資料庫：
資料量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鐘，因此處理海量資料的利器是OLAP多維分析，即建立資料倉庫，建立多維資料集，基於多維資料集進行報表展現和資料探勘等。
15）使用取樣資料進行資料探勘：
基於海量資料的資料探勘正在逐步興起，面對著超海量的資料，一般色挖掘軟體或演算法往往採用資料插樣的方式進行處理，這樣誤差不會很高，大大提高了處理效率和處理的成功率。一般取樣時要注意資料的完整性，防止過大的偏差。

四：查詢優化
1）對查詢進行優化，應儘量避免全表掃描，首先應考慮

在where及order by涉及的列上建立索引。
2）應儘量避免在where子句中對欄位進行null值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num is null，可以在num上設定預設值0，確保表中num列沒有null值，然後這樣查詢：select id from t where num=0
3）應儘量避免在where子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4）應儘量避免在where子句中使用or來連線條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5）in和not in也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用between就不要用in了：
select id from t where num between 1 and 3
6）下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
若要提高效率，可以考慮全文檢索。
7）如果在where子句中使用引數，也會導致全表掃描。因為SQL只有在執行時才會解析區域性變數，但優化程式不能將訪問計劃的選擇推遲到執行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where [email protected]
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where [email protected]
8）應儘量避免在where子句中對欄位進行表示式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9）應儘量避免在where子句中對欄位進行函式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10）不要在where子句中的“=”左邊進行函式、算術運算或其他表示式運算，否則系統將可能無法正確使用索引。
11）在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。
12）不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類程式碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
13）很多時候用exists代替in是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14）並不是所有索引對查詢都有效，SQL是根據表中資料來進行查詢優化的，當索引列有大量資料重複時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15）索引並不是越多越好，索引固然可以提高相應的select的效率，但同時也降低了insert及update的效率，因為insert或update時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16）應儘可能的避免更新clustered索引資料列，因為clustered索引資料列的順序就是表記錄的物理儲存順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新clustered索引資料列，那麼需要考慮是否應將該索引建為clustered索引。
17）儘量使用數字型欄位，若只含數值資訊的欄位儘量不要設計為字元型，這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線時會逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18）儘可能的使用varchar/nvarchar代替char/nchar，因為首先變長欄位儲存空間小，可以節省儲存空間，其次對於查詢來說，在一個相對較小的欄位內搜尋效率顯然要高些。
19）任何地方都不要使用select * from t，用具體的欄位列表代替“*”，不要返回用不到的任何欄位。
20）儘量使用表變數來代替臨時表。如果表變數包含大量資料，請注意索引非常有限（只有主鍵索引）。
21）避免頻繁建立和刪除臨時表，以減少系統表資源的消耗。
22）臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重複引用大型表或常用表中的某個資料集時。但是，對於一次性事件，最好使用匯出表。
23）在新建臨時表時，如果一次性插入資料量很大，那麼可以使用select into代替create table，避免造成大量log，以提高速度；如果資料量不大，為了緩和系統表的資源，應先create table，然後insert。
24）如果使用到了臨時表，在儲存過程的最後務必將所有的臨時表顯式刪除，先truncate table，然後drop table，這樣可以避免系統表的較長時間鎖定。
25）儘量避免使用遊標，因為遊標的效率較差，如果遊標操作的資料超過1萬行，那麼就應該考慮改寫。
26）使用基於遊標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27）與臨時表一樣，遊標並不是不可使用。對小型資料集使用FAST_FORWARD遊標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的資料時。在結果集中包括“合計”的例程通常要比使用遊標執行的速度快。如果開發時間允許，基於遊標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28）在所有的儲存過程和觸發器的開始處設定SET NOCOUNT ON，在結束時設定SET NOCOUNT OFF。無需在執行儲存過程和觸發器的每個語句後向客戶端傳送DONE_IN_PROC訊息。
29）儘量避免大事務操作，提高系統併發能力。
30）儘量避免向客戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理。