MySQL性能优化需围绕“慢在哪、为什么慢、怎么快”三层逻辑：先通过慢查询日志和EXPLAIN定位瓶颈；再基于B+树原理做索引优化；接着优化SQL写法与表结构；最后在配置与架构层面合理调整。

MySQL 性能优化不是堆参数、不是背命令，而是围绕“慢在哪、为什么慢、怎么快”三层逻辑展开。面试官想看的是你有没有系统性排查思路，能不能把原理和实操串起来。

一、先定位瓶颈：从慢查询日志和执行计划入手

不查慢日志、不看 EXPLAIN，就谈优化是空中楼阁。回答时要体现“先观察、再分析”的习惯：

• 打开慢查询日志（slow_query_log=ON，配合 long_query_time 设置阈值），用 mysqldumpslow 或 pt-query-digest 分析高频慢 SQL
• 对慢 SQL 执行 EXPLAIN，重点讲清 type（是否用到索引）、key（实际命中哪个索引）、rows（扫描行数）、Extra（是否回表、排序、临时表）
• 举例：如果看到 type=ALL 且 rows 很大，基本就是全表扫描；Extra 出现 Using filesort 或 Using temporary，说明排序/分组没走索引

二、索引优化是核心：懂 B+ 树，才能写对索引

别只说“加索引”，要讲清楚为什么加、加在哪、加什么类型：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 复合索引遵循最左前缀原则：WHERE a=1 AND b=2 AND c>3，(a,b,c) 有效，(b,c) 无效；范围查询（>、
• 覆盖索引减少回表：SELECT id,name FROM user WHERE status=1；如果 (status,name) 是联合索引，就不需要回主键索引查 name
• 避免索引失效场景：对字段做函数操作（WHERE YEAR(create_time)=2023）、隐式类型转换（字符串字段传数字）、OR 条件中部分字段无索引

三、SQL 写法和表结构要配合优化

很多慢查询，根源不在数据库配置，而在 SQL 本身或设计不合理：

• 少用 SELECT *，只查需要字段；分页深翻用 WHERE id > ? LIMIT N 替代 LIMIT 1000000,20
• 大表避免 ALTER TABLE 直接加字段（锁表、复制数据），用 pt-online-schema-change 或 MySQL 5.6+ 的 ALGORITHM=INPLACE
• 冷热数据分离：订单表按月分表，历史订单归档到历史库；用户表可按 ID 取模分片，避免单表过大

四、配置与架构层面点到为止，体现全局观

这部分不是重点，但提一句能加分，关键是说清楚“为什么调这个、影响什么”：

• innodb_buffer_pool_size 设为物理内存的 70%~80%，保证热数据常驻内存
• query_cache_type=OFF（MySQL 8.0 已移除），因并发更新导致缓存频繁失效，得不偿失
• 读多写少场景可加从库做读负载均衡；超高并发可引入 Redis 缓存热点数据，但要解决双写一致问题