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

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

一、基础优化类（面试高频开场题）

1.索引没用上的常见原因有哪些？举3个实际场景说明

答案：

①字段类型不匹配，比如wherephonephone字段是int类型，隐式转换会导致索引失效；

②使用函数或表达式操作索引字段，比如wheredate(create_time)=2024-01-01，索引无法被正常解析；

③模糊查询以%开头，比如wherenamelike%张三，前缀通配符会让B+树索引失效；

④联合索引不满足最左前缀原则，比如联合索引(a,b,c)，查询条件只写whereb=1andc=2。

2.如何判断一条SQL是否需要优化？从哪些指标入手？

答案：

先看执行效率：生产环境中响应时间超过500ms（视业务调整）的SQL需要重点关注；

再看执行计划：用explain分析，重点看type（是否为all、index等低效类型）、key（是否命中预期索引）、rows（扫描行数是否过多）、Extra（是否有Usingfilesort、Usingtemporary等警告）；

还要看资源占用：通过showprocesslist看是否有长期运行的SQL，或监控数据库CPU、IO使用率，若某条SQL频繁执行且占比高，即使响应时间短也需要优化。

二、查询优化类（核心实操题）

3.有一张订单表order（id主键，user_id普通索引，create_time普通索引，amountint），优化以下SQL：

selectuser_id,sum(amount)fromorderwherecreate_timebetween2024-01-01and2024-04-01groupbyuser_id;

答案：

①建联合索引(create_time,user_id,amount)：利用最左前缀原则命中create_time范围查询，user_id和amount作为覆盖索引，避免回表和Usingtemporary（分组无需建临时表）；

②避免函数操作：若原SQL有date(create_time)需改为直接用create_time对比，确保索引生效；

③分表场景（若数据量超千万）：按create_time分表，先查询目标分表再聚合，减少扫描范围。

4.什么是索引覆盖？什么时候用最合适？

答案：

索引覆盖是指查询的字段（select、where、groupby、orderby）都包含在索引中，无需回表查询主键对应的行数据。

最合适的场景：①高频查询的简单SQL（比如列表页查询用户ID、昵称、头像）；②避免Usingfilesort和Usingtemporary的分组/排序SQL；③大表查询（减少磁盘IO，提升响应速度）。

反例：若查询字段过多（比如select*），建覆盖索引会导致索引体积过大，反而降低写入性能。

三、存储引擎与配置类

5.InnoDB和MyISAM的核心区别？实际项目中为什么优先用InnoDB？

答案：

对比项

InnoDB

MyISAM

事务支持

支持ACID

不支持

锁粒度

行锁（适合高并发写）

表锁（写操作阻塞全表）

崩溃恢复

支持（redo/undo日志）

不支持（易丢数据）

外键

支持

不支持

适用场景

电商订单、支付等核心业务

博客、报表等读多写少场景

优先用InnoDB的原因：①核心业务需要事务保证数据一致性（比如下单扣库存、支付转账）；②高并发写场景下，行锁比表锁冲突更少，并发性能更好；③崩溃恢复机制避免数据丢失，稳定性更高。

6.MySQL配置优化中，哪些参数对性能影响最大？（举3个并说明用途）

答案：

①innodb_buffer_pool_size：InnoDB缓存池大小，建议设为物理内存的50%-70%（比如16G内存设10G），缓存索引和数据，减少磁盘IO；

②max_connections：最大并发连接数，默认151，根据业务调整（比如电商峰值设500-1000），避免连接数不足导致“Toomanyconnections”；

③slow_query_log+long_query_time：开启慢查询日志，设置慢查询阈值（比如1秒），用于定位需要优化的SQL；

④innodb_flush_log_at_trx_commit：事务日志刷盘策略，0=每秒刷盘（性能高但可能丢1秒数据），1=每次事务刷盘（默认，ACID安全），2=事务提交刷到内存，每秒再刷盘（折中方案）。

四、进阶优化类（加分题）

7