井迪迪迪迪迪
1億個其實並不多，不需要什麼集群、數據庫之類，就算加個倍10億個，只需要預處理一下，（hash或其它方法歸併）映射寫入到N個文件中，N要取個合適的值，保證每個文件不會太大或太小，太大太小都會失去歸併的意義，甚至不如直接查找的效率。因為不需要排序，這個歸併過程很快。查找的時候把要查找的號碼進行hash歸併計算就知道會存在哪個文件，直接在這個文件裡找就行了，找不到也不可能存在別的文件中那就是不存在了。當然如果是需要毫秒級的話另說，得看應用場景，以及成本的綜合考慮。
瘋子
我來搗亂一下，1億個QQ號的文件，不用管他是怎麼存放，放在那都行。
然後你只要告訴我你要找的那個qq號，我就能立即告訴你你要找的QQ號是什麼。這個什麼算法都不用。
好吧話回正題，1億個QQ號，對應著什麼？用一個QQ號是要確定在不在這個文件當中，還是說，這個文件裡每個qq號都對應著一個暱稱，要得到這個暱稱呢？
這兩種算法是完全不一樣的，如果只需要確定是否存在，最價辦法應該是布隆過濾器，只需要構建一個信息指紋的大文件，通過集群，可以把速度縮減到毫秒級。
如果是找對應關係，之前的信息指紋就不行了，如果想夠快，依然需要一個集群，先按qq號的最大位數做一個大集合，然後把這1億個qq號按對應位置存入集合，最後把這個集合按0xFF分解到對應的機器上，查找時，只要把QQ號換算成地址，就可以直接訪問了，速也不慢，只是空間上比較浪費，實際做的時候，應該還會做一定的壓縮，以避免空間浪費，但這就需要使用cpu時間了，極限速度挑戰的話，應該不會用這個。
迷人的呆子
哈哈，我看了下都是扯犢子，什麼文本直接點開，你試過沒有。
我來給大家吹吹牛，大概是在15.16年左右，脫庫非常猖狂，網上流傳了各大網站平臺的註冊賬號數據庫，網易的，騰訊的，以及各種中小企業網站數據庫，比如YY，那時候360雲盤可以存40TB+的內容，我就逛各大黑客網站論壇，有幸蒐集了多達38T的數據庫資料以及視頻，只要洩露了，基本上都被收集了，大多數dat這些數據庫文件，需要******才能打開看，還有些是txt文件格式的，比如最出名的一個就是3億QQ賬號密碼那個文件，整個文件有幾G，如果按照其他答主的說法直接打開就行了，可以基本上點開就會卡死，打不開。
其實有很多種辦法可以打開，最簡單的一種，用****軟件切割，把一個txt文件分割為幾十個幾百個幾千個，比如分割為每個文件為100kb，或者把1開頭的分成一個文件，分為多個。這樣子你就能打開了，但是這樣子分割好之後不用打開，蒐集到一個目錄用*****彙總搜索自己需要的就行了。還有一種就是用SQL server這些打開。當然還有其他方法就不一一闡述。
好了牛吹完了360雲盤也封了給你們驗證不了。。。就當吹牛的吧
歡樂深圳
1億qq號，按照每個文qq號11位算，大概佔用1.02g空間，因為數據量不大，可以全加載進內存。這樣的話可以有好多方法。
第一種是內存映射文件，Windows內存映射文件可以映射磁盤上的大文件，別說1g，就算10g也沒問題，然後操作就跟在內存操作一樣，我之前試過500m的純文本（打印的π），用c語言函數strstr查找字符串就能秒得結果，1g跟500m區別不大。
第二種方法，同樣是建立在數據量不大的基礎上，可以構造map存在內存中qq號就是key，因為map基於hash預算，查詢效率非常高，也是秒得結果。
第三種存數據庫，因為數據達到億級，還是考慮oracle這種單表性能爆表的比較好，放mysql估計比較懸。
第四種可以用內存數據庫，如redis，其中key存為qq號，人家專業幹這個的，也是秒得結果。
第五種es，其實es幹這個有點大材小用。
清風14518071
布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都比一般的算法要好的多，缺點是有一定的誤識別率和刪除困難。
基本思路如下:
如果想要判斷一個元素是不是在一個集合裡，一般想到的是將所有元素保存起來，然後通過比較確定。鏈表，樹等等數據結構都是這種思路. 但是隨著集合中元素的增加，我們需要的存儲空間越來越大，檢索速度也越來越慢(O(n),O(logn))。不過世界上還有一種叫作散列表（又叫哈希表，Hash table）的數據結構。它可以通過一個Hash函數將一個元素映射成一個位陣列（Bit array）中的一個點。這樣一來，我們只要看看這個點是不是1就可以知道集合中有沒有它了。這就是布隆過濾器的基本思想。
Hash面臨的問題就是衝突。假設Hash函數是良好的，如果我們的位陣列長度為m個點，那麼如果我們想將衝突率降低到例如 1%, 這個散列表就只能容納m / 100個元素。顯然這就不叫空間效率了（Space-efficient）了。解決方法也簡單，就是使用多個Hash，如果它們有一個說元素不在集合中，那肯定就不在。如果它們都說在，雖然也有一定可能性它們在說謊，不過直覺上判斷這種事情的概率是比較低的
互聯網說事兒
我看了很多小夥伴的回答都說的還不錯，但是很多都想當然的說的，我來說說真實案例，相信大家看了之後，對這一大類知識都有很全面的瞭解。
先科普一下QQ密碼為什麼會被洩露相關知識。只要是軟件和網站就會存在漏洞，當這個漏洞被發現的時候相關公司就會緊急修復，但是有時候這個漏洞沒有被發現或者只是個別的黑客發現沒有公佈出來，這個時候漏洞就叫0day漏洞。還有就是某些漏洞是沒辦法修復的，比如三次握手時候容易被抓取密碼，所以騰訊有時候也沒辦法避免有漏洞，所以也曾被脫褲。
大概是13年左右時候，騰訊曾遭到黑客攻擊，當然後面被緊急修復了。但是在這過程中大約有三億QQ賬號和密碼被脫褲（脫褲是隻黑客從竊取公司數據庫相關信息），至此在各大黑客論壇網站都流傳著一個3億QQ數據庫的文TXT文檔，這個文檔大約佔2G內存，裡面存在著3億qq和對應的明文密碼。這個是真實的，我有一個朋友也曾下載下來驗證證明是真實的。
以這個文件為例，查看最有效的方案有兩個。
1、txt文件切割，用txt文件切割器把這幾G文件切割成100kb/50kb文件，因為單獨一個幾G的TXT文件你用電腦肯定打不開的，一定會卡死。所以切割成幾十份幾百份才能進行查看，當分割成幾百份之後我們可以建立一個本地數據庫，道理很簡單，在自己電腦上新建一個文件夾，把這些切割好的txt文檔歸納到這個文件夾，再用txt搜索軟件**對這個文件夾進行搜索，比如搜索某個QQ，他就會出現相對應的QQ密碼，這樣子搭好了本地數據庫並對裡面的密碼進行了查看。
2、存數據庫，掛到mysql上。掛到mysql上之後我們就可以直接對數據庫進行查看，當然也就可以檢索某個數值了，甚至你還可以就行分類，比如1開頭的QQ分類，比如對6/78位數的QQ進行分類，分類的原因就是便於管理，甚至便於做壞事兒，比如6位數的qq人那大都是很久之前的大老闆了，再針對性的進行***，對吧，當然現在騰訊已經修復這個漏洞，你的密碼也強制性換了，所以也幾乎不存在因為這個原因你再被盜號的風險了。
對不起，太強的求生欲只能敘述成這樣，本來可以更加簡潔明瞭的解釋，但我怕犯了忌諱。不單單QQ曾被脫庫，流傳於世最出名的是QQ群關係這個數據庫，有了它之後，人肉就方便多了，只要通過搜索一個QQ就能查到這個人的同學群公司群興趣群等等，以此為媒介跳板，能查到大片大片的用戶。還有網易的、某某酒店的數據庫非常多，因為確實是沒有絕對安全的數據庫，也不能怪這些個公司。
在剛才寫完這篇回答之後，我又再去百度搜索相關褲子時候，沒想到輕鬆地就搜到了，我已舉報。請條友們不要去下載，沒有意義，說不定已經被掛馬了，當心中毒。瞭解網絡安全知識是為了更好的保護好自己，保護未來的生活中信息不被竊取，請條友們一定要珍重。
IT老胡
如果是隻查找一次，就用文本文件打開Ctrl+F。
如果以後需要經常查找，則採用以下方法：
第一步排序，自己開發一個排序函數。
第二步，採用折中法查找。一億個號碼，查找次數不會超過26次即可命中目標。
算法大概如下：
用數組裝入已排好序的數據。
第一步：獲取需要查找到號碼。
第二步：獲取數組第5000萬個（一億的中間）號碼進行對比。
第三步：如果比要查找的號碼大，則再取第7500萬個號碼（後半段的中間）進行比對。如果比要查找的號碼小，則取第2500萬個號碼（前半段的中間）進行比對。
第四步：按第三步的方法循環，直到找到目標號碼。
循環次數不會超過26次。
IT與隱私安全
我的實錄是用bloom filter 或者cock filter 算法來實現快速查找QQ號，具體做法是每一個Qq號映射到內存的一個位，就像red is 的bitset ，這樣1億個位內存不過幾百兆，完全勝任，以判斷是否存在，你可以在GitHub收java. go或者你需要或者熟悉的語言的具體實現，跑一局程序即可，很高興回答你的問題。謝謝
玉璽讀書
最簡單的，grep命令搞定。想加快，先split，再並行跑多個grep。另外一個辦法，perl腳本，先把整個文件讀入內存，在內存裡操作速度很快，再一條條比對。qq號只有十多位，按16位算，16字節，3億為48億字節，大約4.8GB，對服務器來說小case
用戶1362944465344
這是個比較有意思的問題，信息也比較模糊，首先，是在討論檢索的做法（比如用工具）還是在討論檢索的算法（自己寫代碼實現）。
假設在討論檢索的做法，那麼最快的必然是ag了，the silver searcher，ag要比grep快得多，用ag在linux下檢索一遍內核也是極快的，當然，如果是win系統就另說了。
假設在討論檢索算法，那麼要先考慮檢索是一次性的，還是以後還會再檢索其他號碼。
如果以後還會再檢索其他號碼，那麼就首先對1億個qq的文件進行處理，典型的方法比如是前導補0，讓所有號碼長度一致，再排序，然後按地址偏移做hash表存儲，這種做法雖然首次處理需要耗時很長，但以後查詢的話幾乎是直接按照號碼計算偏移來直接訪問，速度極快，如果做1萬次甚至1億次檢索的話，效率就體現出來了。
如果檢索是一次性的，也就是1億個號碼的記錄文件收到並僅檢索一次的話，那麼使用多線程分段暴力檢索是我目前想到最快的方法了。因為任何的對記錄文件的預處理工作都已經相當於把所有記錄擼了一遍，有這個時間已經完成檢索了。
