首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >MySQL 查询慢又不想动业务:索引加法的三步微优化

MySQL 查询慢又不想动业务:索引加法的三步微优化

作者头像
安全风信子
发布2025-11-18 18:49:02
发布2025-11-18 18:49:02
70
举报
文章被收录于专栏:AI SPPECHAI SPPECH

一句话承诺:不改业务逻辑,三步加索引与执行计划观察,实现“够用即好”的读性能提升。

三步法总览

EXPLAIN 快速表

字段

含义

关注点

type

访问类型

ALL为全表,尽量达到 ref/range

key

使用索引

NULL表示未命中索引

rows

估算行数

越小越好(评估扫描成本)

Extra

额外信息

Using filesort/temporary 需关注


示例表结构与索引

代码语言:javascript
复制
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT,
  status TINYINT,
  created_at DATETIME,
  KEY idx_user_status_created (user_id, status, created_at)
);

慢查询示例与优化

代码语言:javascript
复制
-- 慢查询(无索引或索引不佳)
SELECT * FROM orders
WHERE user_id = 123 AND status = 1
ORDER BY created_at DESC
LIMIT 20;

-- 优化方式:覆盖索引与顺序
-- 索引顺序与过滤列优先,排序列放末尾
ALTER TABLE orders
ADD INDEX idx_user_status_created (user_id, status, created_at);

-- 观察执行计划
EXPLAIN SELECT * FROM orders
WHERE user_id = 123 AND status = 1
ORDER BY created_at DESC
LIMIT 20;

少量解释

  • 过滤列(WHERE条件)应放在复合索引前部,排序列(ORDER BY)理想情况下包含在索引末位。
  • EXPLAIN 的 type 从 ALL 变为 range/ref,通常意味着性能显著改善。
  • 记录变更前后 rowsExtra 字段对比,确认是否消除了 filesort/temporary。

常见坑与替代法

  • 坑:为每个条件单独建索引,导致优化器选择不佳。替代:建立复合索引,匹配查询模式。
  • 坑:忽略选择性,导致索引效果有限。替代:把选择性高的列放在复合索引前部。
  • 坑:覆盖索引未命中 ORDER BY 导致 filesort。替代:把排序列包含在索引中。

下一篇预告

Redis 缓存“偶尔失效”的三种常见坑与兜底策略(流程图+Key设计)。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2025-10-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 三步法总览
  • EXPLAIN 快速表
  • 示例表结构与索引
  • 慢查询示例与优化
  • 少量解释
  • 常见坑与替代法
  • 下一篇预告
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档