即使基数很低的列,如果需要查的具体值是占总数的小部分时,在列上设置索引也能起到很好的效果。
最近在工作中遇到了这么一个场景,抽象描述下。
有一个包含状态信息列的表,只有两种status。值分别为0和1。分别代表processing和done。应为业务特点,新进入的行都是processing的,当结束后,即变为done进行归档。因此有大量的done记录,以及很少量的processing。
有一个业务需求是要取出任意一个processing中的记录然后返回给用户进行展示,因此对应的sql语句差不多就是:
select * from the_table where `status` = 0 limit 1
上线的时候没有注意对应的处理,然后发现单个rpc请求居然要耗时500ms,实在是太夸张了。
当时和同事讨论,同事认为这个列的基数或说区分度只有2,建索引的意义不是很大。书上看到的也是说一般在基数很大的时候建,效果会好。
在测试环境的表截张图,差不多就这个情况:
但我从B树索引的原理上思考,虽然只有0和1两个值,但是因为0的实时数量非常的少,而我们只需要找这个很少的值,所以B树可以锁定少的几条边定位到对应的数据:
然后就在线上数据库提交建了个索引。
然后,对应接口的延迟看看效果。
太强了。
总结:索引能不能起到很好的效果主要看的是会被检索的值占的总量的比例,如果都有可能被检索到时才是基数越大越好。