mysql 索引十连问｜ 剑指 offer - mysql

如下是结合网上及此前面试时遇到的一些关于mysql索引的面试题。
若对mysql索引不太了解可先翻阅相关文章

• 大白话 mysql 之深刻浅出索引原理 - 上

• 大白话 mysql 之深刻浅出索引原理 - 下

  什么是索引？

  索引相似书本的目录，查询书中的指定内容时，先在目录上查找，以后可快速定位到内容位置。在数据库中一般经过B树/B+树数据结构实现。

主键索引和非主键索引有什么区别？

主键索引树中叶子节点存储的是整行数据，而非主键索引叶子节点上保存的是主键的值。使用非主键索引时，先从非主键索引获取到行对应主键ID，以后再根据id在主键索引树上搜索对应行数据，这个过程也被称为回表。

通常使用什么字段做为主键，为何？

通常使用innodb的自增整数类型做为主键：

• 由于自增，容易保证主键索引的有序性，同时还能避免新数据中间位置插入时致使的页分裂；
• 二级索引叶子节点上保存的是主键值，整数类型主键长度较小，二级索引树占用的空间较小。

索引使用场景

where

为查询条件字段建立索引，以达到快速过滤指定条件数据的目的。

## order by
当使用order by将查询结果按某个字段排序时，可考虑为该字段建立索引。没有索引时，会先将查询结果放到内存中进行排序（若内存空间不足，会利用磁盘辅助排序），比较影响查询效率。
索引自己是有序的，能够直接按索引的顺序逐条回表取出数据便可。若是是分页查询，效果更好，这时候只须要取出某个范围的索引对应的数据，而不须要取出全部知足条件的数据排序后再截取返回分页数据。

join

使用join时，为被驱动表的关联字段建立索引，能够有效提升查询效率。好比select * from t1 straight_join t2 on (t1.a=t2.a) where t1.b = 'xxxx'; t2的字段a上有索引，查询过程会是先从表1中依次取出知足条件的行数据，以后用行数据中的a字段去t2上匹配后将两表字段拼接返回，此时能使用到t2.a的索引，避免了t2全表扫描。

索引覆盖

若是select字段+where字段字段列数不太多且查询频繁时，能够考虑为select和where字段建立联合索引，避免查询时回表，提升查询效率。好比select a from t where b = ‘xx’, 建立联合索引(b, a)， 此时扫描索引树后，就已经获得须要查询的字段a了，不须要再回表。须要注意的是联合索引字段的顺序，这个语句没法使用到索引(a, b)。

建立索引须要注意的地方

• 最左前缀匹配原则，联合索引须要注意索引字段的顺序，mysql 会一直向右匹配直到遇到范围查询 (>、<、between、like) 就中止匹配，好比 a = 1 and b = 2 and c > 3 and d = 4 ,若是创建 (a,b,c,d) 顺序的索引，d 是用不到索引的。
  字段是否用到索引的意思是字段是否能利用字段在索引中的有序性进行快速过滤。索引(a,b,c,d), 在索引树上是先按a进行排序，再按b进行排序，以此类推，排序规则相似order by a,b,c,d。上面查询条件中，a定值，b是有序的；b定值，c是有序的；c范围查询，剩下的d是无序的。因此d没法使用到该索引。
• 基数小，区分度低的不适合建立索引。好比性别，最多基数最多总共就3个，此时索引过滤性能不高，查完索引后还需回表，可能比直接全表扫描效率更低。
• 更新频繁的字段建立索引时要权衡索引维护成本。
• 尽可能扩展索引，好比已经有a索引，如今要加 (a,b) 的索引，那么只须要修改原来的索引便可。
• 避免对text大字段建立索引，会致使索引树太大，查询效率不高。若是大字段前n个字符区分度较高，能够考虑建立前缀索引，只索引开始的部分字符，这样能够节约索引空间，提升索引效率。其缺点是不能用于ORDER BY和GROUP BY操做，也不能用于覆盖索引(由于前缀索引树上只有字段的部份内容，须要进行回表)。

何时索引会失效？

• 模糊查询时查询条件以”%”开头没法使用到索引
• 使用or查询时，只有当全部的查询条件字段都有索引才能使用到，好比a=1 or b = 2,只有当a和b都有索引才能使用到索引。
• 数据类型出现隐式转换，如varchar不加单引号的时候可能会自动转换为int类型，这个时候索引失效。
• 在索引列上使用IS NULL或者 IS NOT NULL 时候，索引失效，由于索引不会索引空值。
• 在索引字段上使用”NOT、 <>、!=、NOT IN “时是不会使用索引的，这时只会进行全表扫描。
• 对索引字段进行计算操做，函数操做时不会使用索引。
• 当优化器以为全表扫描速度比索引速度快的时候不会使用索引。通常出如今全表数据比较少的状况下，这时全表扫描比在非主键索引上查找后再回表速度可能更快。
• 联合索引时，查找不知足最左匹配规则，没法使用到联合索引。

innodb使用b+树做为索引模型的缘由

Mysql设计的使用场景比较普遍，须要对遍历查询、单条查询、数据更新都须要较好的性能支持。B+树的特性是只在叶子节点上存储数据。能够从数据读写方面与哈希表、有序数组、b树其余几种索引模型进行比较：

• 哈希表：哈希表只能进行等值查询，在处理范围查询和排序查询时，须要全表扫描哈希表。
• 有序数组：有序数组在进行数据更新时成本较大。往数组中间位置添加数据时，须要移动后面的数据位置。
• B树：b树在非叶子节点上也存储数据，在遍历数据时，须要对不一样层级的节点上的数据进行拼接和排序，这会致使屡次磁盘io。查询效率较低。

如何删除百万级别或以上的数据？

能够考虑先删掉表的索引，等删除数据后再重建索引。当咱们在进行数据修改时，须要同时修改索引，这些额外的索引维护成本较低数据修改的效率；同时，大量的数据删除会致使索引数据页产生大量的碎片空间，此时删除数据后重建索引可使索引树更“紧凑”，提升磁盘空间利用率。

Innodb中的B+树模型中，N叉树的N可否被修改？

1. 经过调整索引字段大小来修改
   N 叉树中非叶子节点存放的是索引信息，索引包含 Key 和 Point 指针。Point 指针固定为 6 个字节，假如 Key 为 10 个字节，那么单个索引就是 16 个字节。若是 B + 树中页大小为 16 K，那么一个页就能够存储 1024 个索引，此时 N 就等于 1024。咱们经过改变 Key 的大小，就能够改变 N 的值。
2. 经过修改页大小间接修改，页越大，每页存放的索引数量就越多，N就越大。

数据页调整后，若是数据页过小层数会太深，数据页太大，加载到内存的时间和单个数据页查询时间会提升，须要达到平衡才行。

如何知道语句有没有走索引查询？

能够利用 explain 查看 sql 语句的执行计划，经过执行计划来分析索引使用状况。

写在最后

喜欢本文的朋友，欢迎关注公众号「会玩 code」，专一大白话分享实用技术。

公众号福利

回复【mysql】获取免费测试数据库！！
回复【pdf】获取持续更新海量学习资料！！