如何治理慢 sql？
选中新版正文中的对应文字，然后点“定位到这里”。
- 一.背景
- 二.MySQL是如何评估成本的？
- 三.即使加了索引，也没有起作用
- 四.内存碎片也是一个值得关注的问题
- 五.前缀索引的坑
- 六.索引合并
- 七.有时候SQL没啥问题，但还是报了慢查询？
- 八.总结
一.背景
今年初团队开始推行“服务稳定性问题治理专项”。通过错误日志、慢SQL、接口性能等各项指标的优化，进一步提升系统稳定性与可靠性。在此契机之下，本文将从“慢SQL治理”的角度，通过部分实际案例，分析其原理，做一些阶段性总结和思考。
二.MySQL是如何评估成本的？
某日线上突发告警，发现有一条慢SQL
select * from xxxx_supplier_extra
where column_key = 'xxxx'
作为有“临床经验”的老司机，第一直觉是先用explain分析。explain用了毫秒级的时间就输出了这样一份执行计划，果然它很快，两分钟都不到。
通过“key=null”，我们不难发现，这条SQL走了全表扫描。这是一条简单的SQL案例，我们借用来分析MYSQL背后的成本评估原理。
执行SQL前，优化器会先选择它认为成本最低的方案。正如同有电梯坐电梯，没电梯爬楼梯。
由于没有可供选择的索引，执行器选了全表扫描。查询成本一般由IO成本和CPU成本组成。众所周知，表数据是存储在磁盘的，每次读磁盘上的数据都 产生IO，受制于磁盘的物理属性，IO往往占查询成本的大头。举个例子，key_name="input_time"这行记录存储在磁盘页A中，读完这行后，又读了页B中的数据key_name...
未能定位到原文的划线
已加入星球，可直接知识星球授权登录
二哥编程星球目前包含：
企业级Agent工作流编排项目PaiFlow
Vibe Coding版本的PaiAgent
派聪明RAG AI知识库Java版本+Go版本
微服务 PmHub、技术派、MYDB
求职派JobClaw（OpenClaw/Hermes架构
PaiCLI（类似Claude Code的Agent
派简历（代码已完成）
等实战项目。
企业级Agent工作流编排项目PaiFlow
Vibe Coding版本的PaiAgent
派聪明RAG AI知识库Java版本+Go版本
微服务 PmHub、技术派、MYDB
求职派JobClaw（OpenClaw/Hermes架构
PaiCLI（类似Claude Code的Agent
派简历（代码已完成）
等实战项目。
1. 微信扫右侧的优惠券加入知识星球
2. 解锁星球的实战项目教程和源码： 项目源码+教程获取
真诚点赞 诚不我欺
回复