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+ 树，才能写对索引
别只说“加索引”，要讲清楚为什么加、加在哪、加什么类型：
- 复合索引遵循最左前缀原则：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 取模分片，避免单表过大
四、配置与架构层面点到为止，体现全局观
这部分不是重点，但提一句能加分，关键是说清楚“为什么调这个、影响什么”：