mysql某千萬級數據表中某欄位有100多種取值，該欄位適合加索引嗎？

01-12

mysql某表中大約1000萬左右數據，其中某欄位只有100多種取值，某些語句查詢條件需要用到此欄位，此欄位適合加索引嗎？

謝 @海洋邀，這個問題，我就只按字面的意思+一些假設來回答

也就是 select * from table_name where state=XX, table_name表有1KW條記錄，這個表有不少於三個欄位，state有100+種取值並且這些取值所佔的比例相當。

那加索引合適。

目測可以加。查詢數據的效率主要是集中在IO的成本上。加不加索引的主要切入點是:索引之後，回表查數據的量+索引的大小是否小於全表取出的數據量，越小越好。你的這種情況，該欄位100種值，如果分布還算均勻的話，查一種值回表平均要查10萬條數據，那麼10萬條數據的大小+索引的大小，應該還是比較小於1000萬數據的。理論歸理論，理論只能告訴你為什麼可以這樣做，但能不能這樣做要根據自己的情況。最簡單最實際的辦法就是去測試，效果一下便明了。解決方案如果不局限樓主的提問的話，最好的解決辦法是用該欄位進行分區或者分表。或再加上索引。

不建議做二級索引，但欄位如果不太長的話，也許可以做主鍵前綴

幾個月前，我看到過一個知乎網友關於index的回答，深以為然。

在知乎上問該不該加索引的任何問題，直接回答：該加。就足夠了。

http://www.cnblogs.com/y-rong/p/5908236.html

不同意樓上答案中的部分觀點，複合索引(聯合索引，多列索引，隨你怎麼叫)就好了（你只加一個索引肯定要回行這麼多啊，複合索引就好些了，一個欄位過濾百分之一，兩個欄位就過濾掉萬分之一了）。

效果好不好的話，還是依前人答案中建議試一試，分析一下時間就好了。

不如加個索引測試一下呢？如果能做到索引覆蓋的話應該有較大幫助。

加索引肯定會有幫助，但是10萬的碰撞，嗯，幫助不是特別大

你應該換一種搜索演算法，盡量換一種演算法來搜索

邀請我回答嗎？我可以把你帶到溝里：）

要綜合實際情況考慮，如果這張表沒有其他的頻繁的SQL，就可以加。

如果表有其他頻繁的SQL就慎重考慮，因為每增加一個索引對其他的查詢都會有影響。

瀉藥。加！只不過要選擇合適的索引。看該欄位是數值型還是字元串類型，是否有規律（前綴相同還是完全隨機）。加完以後測一下，別直接線上加。如果要線上加，選擇閑時。5.5構建索引時，阻塞讀寫操作，我當時用的pt-online-schema-change 可以使用。

謝邀～似懂非懂，還是不要把大家方向帶錯了

你還不如根據這個欄位做hash分區的，不過數據量太小，分區看不出效果，如果你的數據增量能保證這個表三個月內數據量上億的話，倒是可以做

邀請我…有什麼用嗎（。

百度了一下專業名詞，很頭大。

據說加索引會降低更新表的速度，但是既然能極高提高搜索效率，而且是需要用到的欄位，哪怕取值少，相比加和不加，哪個損失更大？

…我真的沒學過啊。

欄位值如果跟主鍵是離散分布的話，應該不合適吧。因為索引再回表是一個隨機磁碟操作，而全表掃描是個順序磁碟操作，順序讀盤效率更高。

一百多種值，可以拆多一張字典表了，拆了查詢效率更高

你不會加了索引然後查看一下各個功能的sql語句的執行計劃嗎?

不會?那你還是加吧.

就算加了索引，默認也不會用。

適合，而且肯定需要，目測你肯定會用到這個欄位做區分去查詢。不過這個區分度你可以考慮以這個為開始，做複合索引

看看欄位是否過長，如果過長的話可以做主鍵前綴

如樓上回答的一樣，不建議，碰撞太高，換成資料庫內部的術語就是選擇率不高，回表10萬次的代價也是很大的，一般也是很難選到這個索引的。建議你考慮下是否表設計不夠合理，這種情況一般可以拆解成字典表和數據表了，還可以更省存儲空間。