1. 选择性较低的列是否适合加索引?
索引选择性等于列中不重复(distinct)的行数量(也叫基数),与记录总数的比值。范围在0-1之间。数值越大,索引越快。
例如主键是唯一的,不重复的,所以选择性=1。
常见的选择性较低的列,例如是否热门,要不1,要不0。选择性等于2/记录总数,所以是非常低的。
而这种列适合加索引吗?
答案是要区分看待:
假如表中是否热门is_hot=1的行有100行,is_hot=0的行有100w行。
那么
如果需求是查询is_hot=1的行,我们设置索引idx(is_hot)是有用的
如果需求是查询is_hot=0的行,我们设置索引就没什么用了。
测试:
100w的表,type=1的有11行,其他都是type=2
没有设置type索引,搜索type=1,要检索100w行,也就是全表扫描,用时0.7s
加了type索引,搜索type=1,只要检索11行,用时0.04。搜索type=2,也是要检索100w行,用时0.7s,也是差不多全部扫描
2.Mysql的索引是否会自动加上主键
假如ID是主键,索引a(SongType)和索引b(SongType,ID)是否等价,也就是Mysql是否会为索引加上主键ID?
答案是不会的
测试:
有100w数据,前50w SongType=1,后49w SongType是2,最后1w SongTYpe=1,ID是主键
有索引a(SongType) 。
sql :select * from table where id>500000 and SongType=1。
会使用主键索引,需要检索行50w行。用时0.5s
加索引b(SongType,ID)后,会使用索引b,只需要扫描1w行数据。用时0.02s
所以索引a,并不会包含主键
3. 多列排序时使用索引的坑
A key_part specification can end with ASC or DESC. These keywords are permitted for future extensions for specifying ascending or descending index value storage. Currently, they are parsed but ignored; index values are always stored in ascending order.
根据Mysql文档的说明,创建索引的时候,可以加上asc或者desc,例如:add index idx(a asc,b desc).但是实际Mysql是会忽略的(好坑。。。)好像8.0版本之后支持desc了。
这会有什么影响呢?
假如有列test1和test2,都是int类型。
我们创建索引``idx1(test1,test2),
假如我们要按test1和test2排序,例如SQL
explain select * from table order by test1 ,test2 limit 1;
可以使用索引的排序:
order by test1
order by test1 desc
order by test1,test2
order by test1 desc,test2 desc
不可以使用索引的排序:
order by test1,test2,desc
order by test1 desc,test2
因为索引不支持desc,所以多列的索引是按全部列的升序存储的。所以只排序一列,全部列升序,全部列降序,都能用索引。但是第一列用升序,第二列用降序,或者第一列降序,第二列用升级,都不能使用索引。
未经同意,请不要转发