直接回答
标准思路是"先定位、再分析、后优化"：通过慢查询日志找到慢 SQL，用 EXPLAIN 看执行计划确认瓶颈（是否全表扫描、索引是否命中、有没有临时表和文件排序），然后针对性优化——加/调索引、改写 SQL、或调整架构（缓存、读写分离、分表）。
展开解析
具体步骤：
- 定位：开启 slow_query_log，配合 mysqldumpslow 或 pt-query-digest 聚合分析，找到执行次数多、耗时长的语句。
- 分析执行计划：重点看 type（要至少到 range/ref，避免 ALL 全表扫描）、key（实际用到的索引）、rows（扫描行数）、Extra（警惕 Using filesort、Using temporary）。
- 优化手段（按成本从低到高）：
- 索引：建联合索引遵循最左前缀；用覆盖索引避免回表；消除索引失效场景（对列做函数/运算、隐式类型转换、前导通配符 LIKE）。
- SQL 改写：避免 SELECT *；深分页改用游标方式；大 IN 拆批；用 UNION 或拆分代替复杂 OR。
- 架构层：热点数据进缓存；读写分离；历史数据归档；实在扛不住再考虑分库分表。
易错点：索引不是越多越好（拖慢写入、优化器可能选错索引）；改完要用 EXPLAIN 和实际压测验证，而不是想当然。