数据库优化面试题及答案.docxVIP

数据库优化面试题及答案

一、基础优化类

1.索引的作用是什么？常见的索引类型有哪些？实际工作中怎么选择？

答案：索引核心是加快查询速度，减少全表扫描的IO开销，同时辅助保证数据唯一性（如主键索引）。

常见类型及选择：

1.主键索引（聚簇索引）：默认自增主键最优，查询时能直接定位数据行，适合作为表的唯一标识，避免用UUID（离散性强，易导致索引碎片）。

2.普通索引（非聚簇索引）：针对高频查询字段（如订单表的用户ID、商品表的分类ID），但要避免过度创建（增删改时会维护索引，消耗性能）。

3.联合索引：多字段组合查询（如“用户ID+创建时间”）时使用，遵循“最左前缀原则”，把查询频率最高、区分度高的字段放前面。

4.唯一索引：适合字段值唯一（如手机号、邮箱），既能加速查询，又能避免重复数据，比普通索引查询效率略高，但插入时会校验唯一性，性能开销稍大。

实际选择：优先保证高频查询路径覆盖索引，避免索引冗余，同时平衡增删改性能（如日志表这类写多读少的表，少建或不建索引）。

2.索引失效的常见场景有哪些？如何排查？

答案：索引失效本质是优化器判断走索引不如全表扫描，常见场景及排查方法如下：

失效场景：

1.索引字段用函数操作（如SUBSTR(name,1,3)、DATE(create_time)），优化器无法识别索引。

2.索引字段参与运算（如id+1=10），破坏索引有序性。

3.模糊查询以%开头（如nameLIKE%张三），无法走前缀索引。

4.联合索引未遵循最左前缀（如联合索引(a,b,c)，只查b和c）。

5.索引字段为NULL，且查询条件用ISNULL/ISNOTNULL（普通索引不存储NULL值，会失效；唯一索引可存储NULL，但仅允许一条）。

6.OR连接的字段，一侧有索引一侧无索引（优化器会放弃索引走全表扫描）。

排查方法：用EXPLAIN分析SQL执行计划，看type列（ALL表示全表扫描，index表示索引全扫描，range及以上表示走索引）、key列（是否命中预期索引）、rows列（预估扫描行数），结合实际执行耗时判断。

二、SQL及查询优化类

1.如何优化慢查询SQL？请结合实际案例说明。

答案：核心思路是“减少扫描行数、避免无效操作、优化索引覆盖”，实际案例步骤如下：

案例：订单表（order）有100万数据，查询“用户ID=123且创建时间在近7天内的订单列表”，原SQL执行耗时5秒。

优化步骤：

1.先查执行计划：发现走全表扫描，user_id无索引，create_time也无索引。

2.建立联合索引（user_id,create_time）：遵循最左前缀，先匹配user_id缩小范围，再按create_time过滤，扫描行数从100万降至几百行。

3.优化SELECT字段：原SQL用SELECT*，改为只查需要的字段（id、order_no、amount），避免回表查询（非聚簇索引需回表取数据），若字段都在索引中，形成覆盖索引，效率更高。

4.调整查询条件：确认create_time用具体范围（如create_timeBETWEEN2026-01-18AND2026-01-25），避免用NOW()-INTERVAL7DAY这类函数（可能导致索引失效）。

优化后耗时降至50ms内，核心是让SQL精准命中索引，减少不必要的IO和数据处理。

2.关联查询（JOIN）如何优化？

答案：关联查询的瓶颈多在“驱动表选择”和“关联字段索引”，优化要点如下：

1.选择合适的驱动表：小表驱动大表（嵌套循环JOIN时，小表作为外层循环，减少内层循环次数）。比如用用户表（10万数据）关联订单表（100万数据），以用户表为驱动表更高效。

2.关联字段必须建索引：JOIN的字段（如user.id和order.user_id）都要建索引，避免关联时对大表全表扫描，这是关联优化的核心。

3.减少关联表数量：非必要不关联多表（超过3张表关联时，性能下降明显），可通过冗余字段、分批次查询后程序拼接等方式优化。

4.避免JOIN时的类型转换：比如关联字段一个是INT，一个是VARCHAR，会导致索引失效，需提前统一字段类型。

5.优化JOIN算法：InnoDB默认支持嵌套循环JOIN，若数据量较大，可调整参数（如join_buffer_size），避免缓冲区不足导致的多次IO。

三、存储引擎及配置优化类

1.InnoDB和MyISAM的核心区别？实际业务中怎么选？

答案：核心区别集中在事务、锁机制、存储结构上，选择需结合业务是否需要事务和并发能力：

区别：

1.事务支持：InnoDB支持ACID事务，MyISAM不支持，崩溃后无法恢复数据。

2.锁机制：Inn