一個大資料量問題的探索（關於分區表的應用）

最近遇到一個資料量大引起的問題， 目前資料量大約8M條資料。以後還將以每天近萬的資料增加。 因此考慮MsSqlServer的分區表特性。
原先的表設計相當於
表名為UserEvent
Id(bigint)，UserId(nvarchar(250)), EventId(nvarchar(250))， column1, column2, column3.

此表相當於一張系統所有業務的索引表， 記錄了某使用者在此系統中所有的業務行為。
應用場合：
每當該使用者在該系統中發生一筆業務， 將在該表中記錄一筆資料。
查詢頁面： 使用者將通過UserId或EventId， 但必須需要兩者中的一個資料進行資料查詢。

由於mssqlserver只支援一個列的分區表的策略， 但是目前的應用情境則必須需要有兩列的資訊（UserId, EventId), 所有從資訊量上的考慮，
分區列也必須包含此兩列的資訊， 因此考慮增加一列：
Id(bigint)，SequenceId(int), UserId(nvarchar(250)), EventId(nvarchar(250))， column1, column2, column3
但是問題隨之而來， 使用者可能只考慮輸入UserId， 或者EventId。 這樣的話導致定位分區表的資訊量不夠， 不能有效利用分區表的特點。
問題總歸沒有答案多呵， 考慮對SequenceId編碼。
暫訂SequenceId為0~99的數字， 十位上的0~9表示EventId的一個編碼， 個位上的0~9表示UserId的一個編碼。這個編碼可以通過HashCode得到後，
再去取得其的個位。 （至於這個編碼， 要看應用場合的， 不然會達不到很好的散列效果的）

這樣的話， 使用者若只輸入UserId(得到的編碼為6)， 則我們可以在查詢條件中， 加入條件（sequenceId in (6，16，26， 36，46， 56，66，76，86，96)）

有什麼好的建議， 不吝賜教。