索引列的数据长度能少则少
数据长度越大-->一个数据块存放的节点越少-->b+tree的路数越少-->深度越高-->io的次数越多-->查询效率越慢。
索引一定不是越多越好,越全越好,一定是建最合适的
索引越多,索引的维护越高,因为是消耗内存和cpu的,因为一个数据的加入,有可能会导致整个B+Tree结构的变化。索引效果不大,因为一个列即使加上索引,但因为离散型低,而不会使用索引。
匹配列前缀可以用到索引
like %999%和like %999用不到索引:因为是最左匹配原则,%和任何字母都无法匹配,like 999%如散列值高,则无法用到索引,若低,则可以
Where条件中not in和<>操作无法使用索引
因为无法匹配
匹配范围值,order by 也可用到索引
最左匹配原则和B+Tree的叶子结点是按照一定的顺序的
多用指定类查询,只返回自己想要的数据列,少用select *
提高覆盖索引的命中率
联合索引中如果不是按照索引最左列开始查找,无法使用索引
最左匹配原则,
联合索引中精确匹配最左列并范围匹配另外一列可以用到索引
联合索引中如果查询中有某个列的范围查询,则其右边的索引列都无法使用索引
暂时没有尝试过
网友评论