先定位慢查询
开启慢查询日志，把超过阈值的 SQL 记录下来：
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;这样执行超过 1 秒的语句都会落盘，配合 mysqldumpslow 工具可以按频率和耗时排序，优先处理出现次数最多的慢 SQL。
读懂执行计划
拿到慢 SQL 后，用 EXPLAIN 查看执行计划，重点看三列：type 表示访问类型，ref 优于 range，最差的是 ALL（全表扫描）；key 显示实际使用的索引，为空说明没用上；rows 是预估扫描行数，数字越大越危险。全表扫描且行数过万，基本就是索引缺失或写得不合理。
索引优化的三个切入点
- 为 WHERE 和 ORDER BY 建索引：查询条件里的字段最该有索引，排序字段建索引能避免 filesort。
- 注意联合索引顺序：联合索引遵循最左前缀原则，把区分度高的字段放前面，查询时按索引顺序写条件。
- 避免索引失效：在索引列上做函数运算、隐式类型转换、前导模糊匹配（
LIKE '%xx'）都会让索引失效，改写语句或调整写法。
别忘了回表与覆盖索引
普通索引查询后还要回主表取数据，一次查询多次 IO。如果查询的字段都在索引里，就能用覆盖索引直接返回，EXPLAIN 中 Using index 就是命中信号。
优化不是一次性的：上线前分析慢日志，上线后观察执行计划变化，配合定期巡检，数据库才能持续保持高效。