1樓：
100/10000000 隨便乙個取值對應都平均有10W條對應的,效率不高,占用的空間太高.
但是如果這個條件是每次查詢必須的話,還是需要加上,效率的話聊勝於無.
如果這個條件是偶爾查詢會用到的話,那麼價效比就太低,不建議加.
所以結論就是看你這個查詢條件用的多不多,有沒有佔80%的查詢以上.
還有就是,分表其實也是空間換時間,至於哪個效率高,還得根據你資料的分布來,測試實踐下最好.
2樓：Frank
要綜合實際情況考慮，如果這張表沒有其他的頻繁的SQL，就可以加。
如果表有其他頻繁的SQL就慎重考慮，因為每增加乙個索引對其他的查詢都會有影響。
3樓：樵夫
瀉藥。加！只不過要選擇合適的索引。
看該字段是數值型還是字串型別，是否有規律（字首相同還是完全隨機）。加完以後測一下，別直接線上加。如果要線上加，選擇閒時。
5.5構建索引時，阻塞讀寫操作，我當時用的pt-online-schema-change 可以使用。
4樓：河南-老宋
謝 @海洋邀， 這個問題，我就只按字面的意思+一些假設來回答
也就是 select * from table_name where state=XX, table_name表有1KW條記錄，這個表有不少於三個字段，state有100+種取值並且這些取值所佔的比例相當。
那加索引合適。
5樓：jusalun
你還不如根據這個欄位做hash分割槽的，不過資料量太小，分割槽看不出效果，如果你的資料增量能保證這個表三個月內資料量上億的話，倒是可以做
6樓：gavin
字段值如果跟主鍵是離散分布的話，應該不合適吧。因為索引再回表是乙個隨機磁碟操作，而全表掃瞄是個順序磁碟操作，順序讀盤效率更高。
7樓：沈杰
目測可以加。查詢資料的效率主要是集中在IO的成本上。加不加索引的主要切入點是:
索引之後，回表查資料的量+索引的大小是否小於全表取出的資料量，越小越好。你的這種情況，該欄位100種值，如果分布還算均勻的話，查一種值回表平均要查10萬條資料，那麼10萬條資料的大小+索引的大小，應該還是比較小於1000萬資料的。理論歸理論，理論只能告訴你為什麼可以這樣做，但能不能這樣做要根據自己的情況。
最簡單最實際的辦法就是去測試，效果一下便明了。解決方案如果不侷限樓主的提問的話，最好的解決辦法是用該字段進行分割槽或者分表。或再加上索引。
現在網際網路應用的資料量越來越大，企業對資料庫優化看的越來越重，同樣也是面試必問項，答好了更是加分項。
由於在知乎上回答關於sql優化方面的問題，因為有教學從業經驗，內容又能很容易看懂，獲得了不少人的認可和點評。所以最後，我又補充了很多乾貨，整理成了筆記，免費送，超過市面上各種培訓機構該部分內容的質量，是個很好的補充。
8樓：
幾個月前，我看到過乙個知乎網友關於index的回答，深以為然。
在知乎上問該不該加索引的任何問題，直接回答：該加。就足夠了。
9樓：今天也要加油鴨
不同意樓上答案中的部分觀點，復合索引(聯合索引，多列索引，隨你怎麼叫)就好了（你只加乙個索引肯定要回行這麼多啊，復合索引就好些了，乙個字段過濾百分之一，兩個欄位就過濾掉萬分之一了）。
效果好不好的話，還是依前人答案中建議試一試，分析一下時間就好了。
10樓：聿明leslie
如樓上回答的一樣，不建議，碰撞太高，換成資料庫內部的術語就是選擇率不高，回表10萬次的代價也是很大的，一般也是很難選到這個索引的。建議你考慮下是否表設計不夠合理，這種情況一般可以拆解成字典表和資料表了，還可以更省儲存空間。
資料表中有出生年月 性別等字段，在資料表中新增身份證號字段是否違背資料庫設計正規化（1NF 3NF）？
飛鳥 正規化的意義在於 資料一致性 如果某個字段存在於好幾個表，就有可能程式設計失誤甚至物理損壞，只更新了部分，從而造成資料不一致。或者，有些字段可以推出另外一些字段，但也是因為程式設計或者維護失誤，沒有完整同步更新，造成資料矛盾。另外，計算機的早期年代，還有儲存空間問題。但是實際環境下，冗餘欄位是...
設計 MySQL 資料表的時候一般都有一列為自增 ID，這樣設計原因是什麼，有什麼好處？
孤狐無悔 回答如下 1 自增ID主要是作為主鍵。2 自增避免重複。3 不一定有優勢，但主要優勢是在滿足主鍵條件的情況下減少開發勞動。不只是MySQL，其他的關係型資料庫，例如MS SQL，Oracle，都有同樣的功能。自增ID列不一定要加，加了不一定有優勢，有時反而有劣勢。但是許多情況加上 並設定為...
MySQL 對於千萬級的大表要怎麼優化？
架構師 每當看到這種問題，總有一大堆人在下邊回答不搭邊的東西，從網上copy 幾萬字的內容對於問題有意義嗎？言歸正傳，mysql單錶到達千萬級別確實會有效能瓶頸，不的不說免費的mysql效能和sqlserver，oracel差的太多了。至於優化，可以做一下幾點 1。網上都寫爛的分庫分表，但是也要根據...