MySQL索引优化面试题及答案（实战版）.docxVIP

MySQL索引优化面试题及答案（实战版）

一、基础理解题（考察核心概念落地）

问题：什么是索引？为什么说索引不是越多越好？实际工作中你会怎么控制索引数量？

答案：索引本质是数据表的“目录”，通过B+树（InnoDB默认）或哈希结构快速定位数据，减少全表扫描。但索引不是越多越好：一是索引会占用磁盘空间（比如一张千万级表的联合索引可能占几G）；二是写操作（insert/update/delete）时，要同步维护所有相关索引，导致写性能下降。实际工作中，我会遵循“按需创建”：只给查询频繁的字段（where、join、orderby）建索引，单表索引数量控制在5-8个以内，定期通过慢查询日志清理无用索引。

问题：InnoDB的B+树索引和哈希索引有什么区别？什么时候用哈希索引更合适？

答案：核心区别在查询场景和排序支持：B+树索引是有序结构，支持范围查询（、、between）、排序（orderby）和模糊查询（likexxx%），适合大多数业务；哈希索引是键值对映射，只能支持等值查询（=、in），查询速度O(1)，但不支持范围和排序。适合用哈希索引的场景：比如缓存表、字典表，查询都是精确匹配（比如根据用户ID查用户信息），且写操作少、读极频繁的场景。

二、设计实操题（考察索引设计逻辑）

问题：有一张订单表orders（id主键，user_id，order_no唯一，create_time，amount，status），常用查询场景：①根据user_id查近3个月的订单；②根据order_no查订单详情；③统计某status下amount大于1000的订单数。请设计索引，并说明理由。

答案：结合查询场景设计3个索引，避免冗余：

场景①：idx_user_create(user_id,create_time)——联合索引前缀匹配user_id，同时覆盖create_time的范围查询，无需回表；

场景②：uniqueindexidx_order_no(order_no)——order_no是唯一标识，建唯一索引既保证数据唯一性，又能快速等值查询；

场景③：idx_status_amount(status,amount)——先按status等值过滤，再对amount做范围查询（1000），符合联合索引“左前缀原则”，查询时直接通过索引统计，无需扫全表。

问题：联合索引的“左前缀原则”是什么？如果查询条件是“whereb=?andc=?”，而联合索引是(a,b,c)，会走索引吗？为什么？

答案：左前缀原则是指联合索引（a,b,c）会优先匹配最左列a，再依次匹配b、c，只有查询条件包含最左列，或按左到右顺序匹配部分列时，才能用到索引（比如wherea=?、wherea=?andb=?会走索引，whereb=?不会）。如果查询条件是“whereb=?andc=?”，联合索引是(a,b,c)，不会走索引——因为缺少最左列a的匹配，索引无法定位到有效范围，数据库会直接走全表扫描。解决办法：要么调整查询条件包含a，要么重建索引为(b,c)。

三、性能优化题（考察问题排查能力）

问题：明明给字段建了索引，查询却没走索引，可能是什么原因？你会怎么排查？

答案：常见原因有6种，排查时先执行explain看执行计划（重点看type、key、rows字段）：

索引列用了函数/运算（比如wheredate(create_time)=2024-01-01、whereid+1=100），导致索引失效；

字符串字段和数值比较（比如wherephone而phone是varchar类型），触发隐式转换，索引失效；

模糊查询以%开头（比如wherenamelike%张三），B+树无法定位前缀，索引失效；

查询条件用了or（比如wherea=?orb=?，只有a或b其中一个有索引时，不会走索引）；

数据倾斜严重（比如status字段90%都是“已完成”，查询wherestatus=已完成时，数据库认为全表扫描比走索引更快）；

索引选择性太差（比如性别字段，只有男/女，建索引反而不如全表扫描）。

排查步骤：先看explain的key是否为目标索引→检查查询语句是否有上述“坑”→查看表数据分布（比如selectcount(distinctstatus)/count(*)看选择性）。

问题：如何优化分页查询（比如limit100000,20）的性能？为什么原查询慢？