這個問題有點意思。但是你的問題過於籠統，不好回答。

首先，你的抽獎名單資料是如何儲存的，還是一個全新的系統，單純就是一個抽獎系統？一次抽獎多少個？

現在就說個比較簡單的情況，假設：你的抽獎名單全部在一個表裡面儲存，裡面有一百萬條資料，要一次性抽中500人。

我的設計思路就是：

首先利用迴圈把100萬條資料插入redis快取伺服器後，插入過程肯定是比較慢的，因為是從資料庫讀入到redis快取。讀入完成後，再使用隨機函式，隨機抽取[0-100)的整數，直接透過index進行索引，快的時候，不用一秒就能命中資料。所以很輕鬆的解決了100萬資料的索引速度慢的問題。

下圖就是100w資料透過redis命中某條資料的速度，可參考以下：

命中了資料之後，為了防止重複命中，當然同時應該使用另外一個redis庫表儲存好命中的結果id，每抽一次資料就跟命中結果比較，存在則重新抽，直到500個不重複的資料抽滿為止。

最後把命中的結果更新到資料庫（如mysql server或者mssql server 等) 進行固化儲存。

另外給你介紹一個我使用的redis工具，方便你參考處理：

redis 儲存的資料型別，可以是整數，字串，陣列，json等，我下面用的是json，你可用key及value 均儲存使用者的id號即可：

下面儲存是陣列：

具體如何安裝redis，可用百度一下，有window是版本，安裝過程也不復雜。

百萬資料搜尋都是很容易的事 更何況是抽獎 抽獎就是隨機抽取那麼幾條資料 和資料總量基本沒什麼關係 不會影響速度 和查詢是兩回事