值重復率高的字段不適合建索引
理論文章會告訴你值重復率高的字段不適合建索引。不要說性別字段只有兩個值，網友親測，一個字段使用拼音首字母做值，共有26種可能，加上索引后，百萬加的數據量，使用索引的速度比不使用索引要慢！
通過上述的實驗數據，我們可以得出關於枚舉字段索引的結論：
如果where 只查索引字段，查詢會使用索引，且效率提升明顯！
如果where 查詢索引字段+非索引字段，如果查詢索引枚舉值較少的這部分數據，效率有提升；
如果where 查詢索引字段+非索引字段，如果查詢枚舉值相差不大或者查詢較多的這部分數據時，索引大大降低了查詢效率！可怕的是，比全表索引效率還要低的多！
枚舉值是否需要建立索引？
通過上述的實驗，我們可以看到有時我們添加索引不僅不會提升效率，反而變成了累贅。
因此對於"枚舉值字段是否要建立索引？"
這個問題需要考慮的因素比較多；
比如表中已有總索引數量、查詢頻率、索引字段修改是否頻繁、是否會索引字段與非索引字段組合查詢等等，需要綜合考慮
經過這一系列的實驗， 並不是說增加索引不會提升效率，而是防止出現"索引字段+非索引字段"這種情況，畢竟這類枚舉值字段用到的地方比較多。
但如果片面的來看的話，單純從"提升查詢未發送記錄數據的效率" 角度來說的話，為send_flag建立索引是會提升效率的。
但是得保證不能出現send_flag條件與其他非索引字段同時使用的情況，否則反而成了累贅。因此是否有必要創建索引，需要綜合考慮到項目其他因素！
例如"sex男女(0\1\2)"這類字段無特殊要求不需要單純查詢，則不需要建立索引
要關注字段作為查詢條件時的影響結果集來建索引，而不是隨便一個字段都可以建！
select count（distinct status）/count（*） FROM 表名。數值越大越適合建索引。status 明顯不適合，status 字段不常變化可選用位圖索引。否則可考慮組合索引；
來源網絡總結；
文章來源：劉俊濤的博客 歡迎關注公眾號、留言、評論，一起學習。
__________________________________________________________________________________
若有幫助到您，歡迎點擊推薦，您的支持是對我堅持最好的肯定(*^_^*)