MySQL索引优化和SQL调优的核心是让查询走对索引、少查数据、避免隐式转换和临时表，关键在于理解执行计划、识别低效模式并针对性改写SQL或创建联合索引，遵循最左前缀原则，善用覆盖索引，规避索引失效写法，并通过EXPLAIN、慢日志等工具持续验证优化效果。
MySQL索引优化和SQL调优不是堆配置、加硬件，核心是让查询走对索引、少查数据、避免隐式转换和临时表。重点在理解执行计划、识别低效模式、针对性改写或建索引。
看懂EXPLAIN，定位慢在哪
每次优化前先 EXPLAIN + 你的SQL，重点关注：
- type：尽量到 ref 或 range，ALL 是全表扫描，危险信号
- key：是否命中了预期的索引？为空说明没用上索引
- rows：预估扫描行数，远大于实际返回行数，说明索引区分度差或条件没过滤好
- Extra：出现 Using filesort 或 Using temporary 要警惕，常因排序/分组没走索引
索引设计要“匹配查询模式”
不是字段越多越好，而是按 WHERE、ORDER BY、GROUP BY 的实际组合建联合索引，遵循最左前缀原则：
- 查询条件是
WHERE a=1 AND b>10 AND c=5，推荐索引(a,b,c)，不是(a,c,b) - 含范围查询（
>,,BETWEEN）后，右边字段无法走索引，如(a,b,c)中b用了>，则c不会生效 - 排序字段尽量包含在索引末尾，例如
ORDER BY a,b配合(a,b)索引可避免 filesort - 覆盖索引很实用：SELECT 只查索引字段，比如
INDEX (user_id, status, create_time)，查这三列就不用回表
SQL写法避坑，别让索引“失效”
再好的索引，写法不对也白搭：
- 避免在 WHERE 字段上做运算或函数：
WHERE YEAR(create_time) = 2024→ 改成WHERE create_time >= '2024-01-01' AND create_time - 避免隐式类型转换：
user_id是 INT，但写成WHERE user_id = '123'可能触发全表扫描；保持类型一致 - 少用
SELECT *，尤其大宽表；只查需要的字段，减少IO和网络传输 -
LIKE模糊查慎用前导百分号：LIKE '%abc'无法走索引；LIKE 'abc%'可以 - OR 条件容易使索引失效，优先考虑 UNION 或拆成多条语句（视数据分布而定）
实战小技巧：快速判断和验证
不靠猜，靠证据：
- 用
SHOW INDEX FROM table_name查当前索引结构，确认字段顺序和是否唯一 - 用
SELECT COUNT(DISTINCT col)/COUNT(*)算字段选择性，低于 0.01 的字段单独建索引意义不大 - 慢查日志（slow_query_log）打开后，结合 pt-query-digest 分析高频低效 SQL
- 新增索引后，务必用
EXPLAIN对比前后执行计划，确认生效且rows显著下降
基本上就这些。索引不是越多越好，SQL也不是越短越好，关键是让 MySQL 少干活、走对路。调优是迭代过程：观察 → 分析 → 修改 → 验证 → 监控。
