数据库索引面试题及答案（实战版）.docxVIP

数据库索引面试题及答案（实战版）

一、基础概念题

问：什么是数据库索引？它的核心作用是什么？实际使用中要注意什么权衡？

答：索引本质是数据库的“快速查找目录”，基于表中一列或多列数据构建的有序数据结构（比如B+树、哈希表）。核心作用是加速查询，避免全表扫描（比如查“用户ID=10086”的记录，有索引直接定位，无索引要逐行遍历）。但要注意“权衡”：索引会占用额外存储空间，且增删改操作时要同步维护索引（比如插入一条数据，既要写表数据，还要更新索引结构），所以不是索引越多越好。

问：索引的“回表查询”是什么意思？怎么避免？

答：以InnoDB的B+树索引为例，二级索引（非主键索引）的叶子节点存储的是“索引列值+主键ID”，而非完整行数据。当查询的字段不在二级索引中时，需要先通过二级索引找到主键ID，再去主键索引（聚簇索引）中查完整数据，这个过程就是回表。避免方式：一是查询时只选需要的字段（不写SELECT*），让查询字段都包含在二级索引中（即“覆盖索引”）；二是合理设计联合索引，把常用查询字段纳入索引。

二、索引类型及区别题

问：InnoDB的聚簇索引和非聚簇索引有什么核心区别？实际业务中怎么影响表设计？

答：核心区别在数据存储方式：聚簇索引（主键索引）的叶子节点直接存储完整行数据，表数据本身就是索引的一部分；非聚簇索引（二级索引）的叶子节点只存“索引列值+主键ID”，不存完整数据。影响表设计：①聚簇索引决定了数据的物理存储顺序（按主键有序排列），所以主键最好用自增ID（避免插入时频繁调整数据物理位置，影响性能）；②非聚簇索引依赖主键，主键太长会导致二级索引占用空间变大，所以主键要尽量短小。

问：哈希索引和B+树索引的适用场景有什么不同？为什么InnoDB默认用B+树而不是哈希？

答：哈希索引的优势是“等值查询”极快（直接通过哈希函数定位），但缺点是不支持范围查询（比如、、between）、排序和模糊查询（like）；B+树索引的叶子节点是有序链表，既支持等值查询，也能高效处理范围、排序、模糊查询（前缀匹配）。InnoDB默认用B+树，是因为实际业务中“范围查询、排序”很常见（比如查“年龄20-30岁的用户”“按创建时间排序”），哈希索引的适用场景太窄，满足不了大部分需求。

问：联合索引的“最左前缀原则”是什么？举个例子说明实际怎么用？

答：联合索引（比如idx(a,b,c)）是按“a→b→c”的顺序构建的，查询时必须从最左边的列开始匹配，才能命中索引。比如：①查a=1→命中；②查a=1andb=2→命中；③查a=1andb=2andc=3→命中；④查b=2或c=3→不命中；⑤查a=1andc=3→只命中a列的索引部分，b和c不生效。实际用的时候要注意：把查询频率最高、区分度最高的列放在联合索引的最左边（比如用户表常用“手机号+验证码”查询，就建idx(phone,code)，而不是idx(code,phone)）。

三、索引设计与优化题

问：设计索引时，哪些情况不适合建索引？为什么？

答：以下情况不适合建索引：①数据量极小的表（比如只有几十条数据，全表扫描比查索引还快）；②频繁增删改的表（比如日志表，每次操作都要维护索引，反而拖慢性能）；③区分度极低的列（比如性别列，只有男/女，建索引后查询效率提升有限，还占用空间）；④查询时用不到的列（比如表中有个“备注”列，从来不在where条件中使用，建索引毫无意义）。核心原则是：索引要为“常用查询”服务，没用或收益小于成本的索引坚决不建。

问：什么是“索引失效”？常见的导致索引失效的情况有哪些？

答：索引失效就是查询时本该命中索引，却因为某些操作导致数据库放弃索引，转而全表扫描。常见情况：①索引列用了函数或运算（比如wheresubstr(name,1,1)=张、whereage+1=20）；②索引列用了不等于（!=、）、notin、isnotnull（部分情况）；③字符串字段不加引号（比如索引列name是varchar，查询wherename=123，会触发类型转换，导致索引失效）；④模糊查询用%开头（比如wherenamelike%张三，B+树只能支持前缀匹配，后缀/中间匹配无法命中索引）；⑤联合索引不满足最左前缀原则。

问：怎么判断一条SQL是否命中了索引？如果没命中，该怎么排查？

答：判断是否命中索引，用数据库的“执行计划”（explain）：看explain结果中的type