其實你的思路已經很對了。

tid上建立索引，依group分錶。

如果group >=3的群組，在程式中動態組合sql如下：

select * from group3 where tid < 100
union all 
select * from group4 where tid < 100
union all 
select * from group5 where tid < 100

以上索引生效，邏輯可用。

首先說明一下，在 Innodb 中，索引生不生效跟你使用 沒有必然關係。也不是說用 = 就一定能用上索引。當全表查的效能要高於索引檢索查詢時，MySQL 會智慧的放棄索引，選擇全表查詢。

如圖：

回到你的問題，如果某個索引，如 tid

如果這兩個索引的結果集都很大的話，是否考慮添加其他過濾條件，例如根據創建時間只查近一個月的內容。

分頁問題也可以透過主鍵ID來再次過濾。

首先，要明白以下幾點：

1. 對於一個表格的查詢，每次最多只使用一個索引

2. 對於聯合索引，從左往右依次進行資料的篩選，所以如果第一個篩選條件針對了大於或小於的話，第二個篩選條件由於在整個可選區域內沒有確切的索引範圍，所以會將第一個篩選條件篩除來的數據都跑一遍

3. B-Tree索引的結構類似樹狀結構，見下圖，聯合索引由左往右的檢索，起始是這個結構從上往下找出分支的過程

4. 索引的機制，簡單說來就是創建一個值到資料項的對應表，這樣可以快速的從某一字段某個值定位到某一行，省卻了跑整個表去找對應行的操作，所以比較快

B-Tree索引的結構：

然後回到你的問題上，如果要大幅度提高效率，那麼聯合索引的第一步就需要大幅度減少可以用於後續篩選的數據量，所以如果你要查tid 的話，先用tid篩選才能夠大幅減少後續的B-Tree索引分支，所以如果要用聯合索引，則應該是(tid, group)。

group條件的篩選性很差，單獨建立索引意義不大。

根據你描述的場景，只要tid的值不是太大（幾千的數量級），針對tid建立索引就可以了。
如果還擔心tid條件過濾後的資料量大，可以建立tid,group的組合索引。

首先非常感謝各位對我問題的關注與回答！ ！
問題解決之後針對boxsnake的建議有一個思考，在這裡發一下。
group_tid這種索引方式除了解決讀取之外還能解決分頁問題，
例如我每頁文章數量是10，用戶級別為3，那麼讀取時分別從group1、group2、group3中，
按範圍tid

但如果用tid_group這種索引方式來讀取，如果需要group比方說取10篇，tid90-tid99，如果他們的group都是4，那麼就無法取出符合條件的數值。
而tid_group在限定group之前又必須對tid進行限定，所以就沒法使用了。