尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
MySQL慢查询优化:从3秒到30毫秒的完整实录
上周三凌晨监控告警突然炸了订单列表接口平均响应时间突破3秒P99更是飙到8秒。用户端大量超时客服电话被打爆。我打开慢查询日志一场从3秒到30毫秒的优化战役就此打响。定位慢查询日志揪出元凶先看慢查询日志一条SQL赫然在目sql复制下载SELECT FROM orders WHERE user_id 12345 AND status 1 ORDER BY create_time DESC LIMIT 10;这张订单表有2000万行数据user_id和status各自有单列索引。EXPLAIN结果让人倒吸一口凉气typeALL全表扫描rows19800000Extra里写着Using filesort。MySQL先扫全表再排序最后取10条——3秒已经算快了。第一步联合索引但顺序有讲究直觉告诉我该建联合索引。先试了(user_id, status)结果typeref但Using filesort依然存在。因为排序字段create_time不在索引里MySQL仍需额外排序。调整为(user_id, status, create_time)后Extra终于变成了Using where; Using index condition排序消失了。响应时间从3秒降到500毫秒。但离30毫秒还差得远。第二步消除回表覆盖索引立功问题出在SELECT。虽然索引命中了但查询需要所有字段MySQL必须拿着主键ID回表查完整行。10条数据就要回表10次如果数据分散在不同页随机IO开销巨大。我改成先查主键再关联取详情sql复制下载SELECT o. FROM orders o INNER JOIN ( SELECT id FROM orders WHERE user_id 12345 AND status 1 ORDER BY create_time DESC LIMIT 10 ) t ON o.id t.id;子查询用上了覆盖索引(user_id, status, create_time, id)不需要回表外层只用10次主键查询。响应时间骤降到80毫秒。第三步细节打磨压榨最后50毫秒80毫秒已经不错但距离30毫秒还有差距。继续排查统计信息过期。ANALYZE TABLE orders更新统计信息后优化器选择了更优的执行计划。缓冲池命中率。检查innodb_buffer_pool_size发现只有2GB而热数据就有8GB。调整为12GB后磁盘IO大幅减少。分页优化。这个接口其实还有翻页逻辑深分页时LIMIT 100000, 10会扫描大量无用行。改用游标分页基于create_time和id做条件过滤。连接池调优。HikariCP的maxPoolSize从20调到50避免高并发下连接等待。一轮组合拳下来再次压测平均响应时间稳定在30毫秒P99控制在50毫秒以内。从3秒到30毫秒整整提速100倍。复盘慢查询优化的四个原则索引不是越多越好顺序决定成败。联合索引要兼顾过滤和排序把等值查询字段放前面范围或排序字段放后面。警惕SELECT。它让覆盖索引失效强制回表。只取需要的列或者用延迟关联。统计信息和缓冲池是隐形杀手。优化器依赖统计信息选执行计划缓冲池大小决定磁盘IO次数。这两项配置不当再好的索引也白搭。深分页必须用游标。LIMIT offset, size在offset大时性能断崖式下跌游标分页才是正解。优化不是一次性的上线后我设置了慢查询阈值200毫秒每天自动推送Top 10慢SQL。毕竟30毫秒的成绩需要持续守护。
RELATED

相关推荐

SurfSense `create_automation` 工具全解析:一次调用完成“意图起草 → JSON 生成 → 人工审批 → 持久化“的自动化创建链路

SurfSense `create_automation` 工具全解析:一次调用完成“意图起草 → JSON 生成 → 人工审批 → 持久化“的自动化创建链路

SurfSense create_automation 工具全解析:一次调用完成"意图起草 → JSON 生成 → 人工审批 → 持久化"的自动化创建链路 【免费下载链接】SurfSense Open-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok,…

📅 2026/9/15 6:39:14
大模型测试的实战坑点与六大测试维度解析

大模型测试的实战坑点与六大测试维度解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/9/15 6:39:14
LLVM后端开发:汇编打印机制深度解析

LLVM后端开发:汇编打印机制深度解析

1. LLVM后端开发中的汇编打印机制解析在编译器开发领域,LLVM后端负责将中间表示(IR)转换为目标机器的汇编代码,其中汇编打印(Assembly Printer)是代码生成流程的最后关键环节。作为一位长期从事编译器开发的工程师,我经常需要为不同指令集架构…

📅 2026/9/15 6:39:14
MORE NEWS

更多资讯

📰

远程会议效率提升指南:从会前准备到会后纪实的完整最佳实践

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

高校学生信息管理系统毕设实战:Spring Boot+Vue全栈开发与部署指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

从TCP/IP数据包到三层架构:Windows+VMware网络实验复盘

最开始我其实只是想搞明白一个问题:在Windows里打开一个网页,屏幕上那几行字,到底是怎么从我电脑的网卡口跑出去,又怎么从服务器上跑回来的。结果这一查不要紧,从TCP/IP协议栈一路看到了交换机和路由器,最后…

📰

JavaScript内存优化实战:定位GC瓶颈与六大泄露场景

1. 这不是“理论课”,是前端工程师每天都在面对的真实战场JavaScript 内存问题从来不是教科书里那个安静的“堆栈模型图”。它是在你刷新页面后 Chrome 任务管理器里突然跳到 1.2GB 的 Edge 进程;是你上线新功能后用户投诉“微信打开就卡死、闪退”&…

📰

彻底清理软件卸载残留:注册表与AppData实操指南

卸载一个软件只需要几秒,可你真的把它“送走”了吗?我在实际维护电脑的过程中见过太多这种情况:控制面板里明明显示“已成功卸载”,但 C 盘空间依旧莫名其妙地缩水,开机速度没有改善,过几天还弹出“Windows…

📰

树莓派GPIO编程:wiringPi库实战指南

1. 项目背景与wiringPi库简介最近在树莓派上折腾GPIO控制时,发现wiringPi这个库确实是个好东西。作为一款用C语言编写的GPIO访问库,它让硬件操作变得像写普通应用程序一样简单。记得第一次用wiringPi点亮LED时,那种"原来硬件编程可以这么…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬