MySQL索引怎么优化 MySQL SQL语句调优技巧【实战】

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) = 2025 → 改成 WHERE create_time >= '2025-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 少干活、走对路。调优是迭代过程：观察 → 分析 → 修改 → 验证 → 监控。