慢SQL诊断

本文讲述了在企业中处理慢SQL问题的方法,包括开启slowlog监控,使用SHOWProfiles和SHOWPROFILE语句进行性能诊断,以及针对不同阶段的SQL执行分析和优化建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 最近经常遇到技术开发跑来问我慢SQL优化相关工作,所以干脆出几篇SQL相关优化技术月报,我这里就以公司mysql一致的5.7版本来说明下。

在企业中慢SQL问题进场会遇到,尤其像我们这种ERP行业。

成熟的公司企业都会有晚上的慢SQL监控和预警机制。不需要我们技术人员过多关注慢SQL的产生和收集,自然会有管理人员通知下来。一般来说慢SQL监控通常都是利用slowlog来实现的,这个比较简单:

mysql 默认是关闭slowlog的,不记录管理语句,也不记录不使用索引进行查找的查询,毕竟这也是一个额外的损耗。最小值和默认值long_query_time分别为 0 和 10。

可以查看是否开启了slowlog:

show variables like '%slow_query_log%';

 如果需要开启可以执行语句:或者去配置文件添加配置

set global slow_query_log=1;

这里就不再展示了,毕竟我们不是DBA。

那么发现了慢SQL之后怎么去定位问题?在mysql官网文档中性能问题诊断分析有提供分析方式。

1、慢SQL诊断SHOW PROFILES

mysql提供了show profiles和show profile语句提供的分析信息相当的数据,但是需要注意的是在未来的mysql中会弃用当前语句功能,使用性能模式performance_schema来替换,从8.0版本文档中确实没有看到这个语句了,但是听别说依旧可以使用,这个先不管了,反正目前看来mysql5.7在23年10月还在更新维护,那就没什么好说的。

确定当前版本是否支持show profiles

 select @@have_profiling;

如果支持那就开启下:(这种是临时开启,启动后会重置)

set profiling=1;

其他内容就不多说了,简单玩意,默认size是15,我这里调成了最大100。

2、已知执行SQL,诊断性能

如果现在你已经知道慢SQL是哪个了,就可以通过profiling来进行诊断。

比如当执行完SQL后,可以通过show profiles来显示发送到服务器的最新语句的列表(除了他自己)。

 接下来就可以通过show profile T for ID 来显示有关单个语句的详细信息。

show profile for query 19;

这里先对show profile语句做个简单的介绍:show profile T for ID

type可以指定 可选值来显示特定的附加类型的信息:

ALL显示所有信息

BLOCK IO显示块输入和输出操作的计数

CONTEXT SWITCHES显示自愿和非自愿上下文切换的计数

CPU显示用户和系统CPU使用时间

IPC显示发送和接收的消息计数

MEMORY目前尚未实施

PAGE FAULTS显示主要和次要页面错误的计数

SOURCE显示源代码中函数的名称,以及函数所在文件的名称和行号

SWAPS显示交换计数

 比如你先查看当前SQL执行时CPU的情况,就可以show profile CPU for query 19,可以显示在各个阶段CPU的消耗。具体的使用可以根据需要来定。

对于show profile的结果,比较重要,这是我们诊断SQL问题的关键。返回内容比较多,都是SQL整个执行过程,我们也不需要关注所有的内容: 

System lock

确认是由于哪个锁引起的,通常是因为MySQL或InnoDB内核级的锁引起的。建议:如果耗时较大再关注即可,一般情况下都还

 Sending data

解释:【数据收集|检索+发送】该线程正在读取和处理语句的行 select,并将数据发送到客户端。由于在此状态期间发生的操作往往会执行大量磁盘访问(读取),因此它通常是给定查询生命周期中运行时间最长的状态。

建议:一般当前步骤耗时久,就是SQL本身的效能问题,可以通过做响应的优化手段,比如索引优化提高检索效率、分页控制数据量等等。

 Sorting result

正在对结果进行排序,类似Creating sort index,不过是正常表,而不是在内存表中进行排序

建议:一般在无索引order by、groupby都会有这样的步骤产生,如果当前阶段耗时久,可以考虑做一些索引优化来避免sort动作,或者进行数据量控制。

Sending to client

服务器正在向客户端写入数据包。Writing to netMySQL 5.7.8之前 称为此状态

 create sort index

当前的SELECT中需要用到临时表在进行ORDER BY排序

建议:一般在无索引order by、groupby都会有这样的步骤产生,如果当前阶段耗时久,可以考虑做一些索引优化来避免sort动作,或者进行数据量控制

 Creating tmp table

创建临时表。先拷贝数据到临时表,用完后再删除临时表。消耗内存,数据来回拷贝删除,消耗时间。

建议:比如groupby或者一些子查询会产生当前步骤,可以通过优化索引来避免

converting HEAP to MyISAM

查询结果太大,内存不够,数据往磁盘上搬了。

建议:优化索引或着数据量优化,可以调整max_heap_table_size

Copying to tmp table on disk

把内存中临时表复制到磁盘上,危险!!!

建议:优化索引,可以调整tmp_table_size参数,增大内存临时表大小

 上面列举一些常见内容项,详细的可以查看官网中资料(processlist):MySQL :: MySQL 5.7 Reference Manual :: 8.14.3 General Thread States d

处理一般线程state,官网还介绍了缓存、I/O线程状态等等。虽然内容是show processlist的,但是也适用于当前

到这里基本上就可以大致有个慢SQL诊断结果了,如果SQL本身需要优化,就可以做响应的执行进化分析过程。

3、线上问题分析定位

如果线上存在正在执行慢SQL,可以通过线程集来定位show processlist

比如当前线上正在慢SQL执行中:

 这样可以知道当前执行中的SQL当前自行过程中的状态,注意这个时实时的,所以可以通过多次观察来看耗时的步骤,比如当前SQL在sending to client持续时间很久,说明数据量很大,导致传输给客户端效率慢。

同时也可以通过explain connection for ID 来查看当前SQL执行计划:

explain for connection  99;

好了,诊断问题完成了,接下来就是具体的SQL分析和优化了。

### 关于SQL优化的方法 #### 使用视图监控SQL 通过使用 `v$long_exec_sqls` 视图,可以初步判断是否存在SQL。如果该视图中有记录,则表明当前系统中存在执行时间较长的SQL语句[^1]。 然而,仅依赖此视图并不足以全面排查SQL问题。为了更精确地捕获和分析SQL,建议启用数据库中的SQL日志功能,以便收集详细的运行数据并进一步诊断。 #### 利用EXPLAIN工具分析执行计划 对于已发现的SQL,可以通过添加关键字 `EXPLAIN` 来查看其执行计划。重点检查以下几个字段: - **Type**: 表示访问类型,通常希望看到的结果是索引扫描而非全表扫描。 - **Key**: 显示实际使用的索引名称,如果没有则可能需要创建合适的索引。 - **Rows**: 预估返回的行数越多,性能越差;应努力减少这一数值。 - **Extra**: 提供额外的信息,比如是否有临时表、文件排序等情况发生,这些都会影响效率[^2]。 通过对上述指标的深入剖析,能够定位到具体导致速度减缓的因素所在,并采取相应的措施加以改进。 #### 调整复杂的SQL逻辑结构 特别需要注意含有大量IN操作符列表项的情况。因为随着IN集合大小的增长,不仅会使生成的整体查询更加繁杂难懂,在某些临界点上还可能导致原本利用高效索引完成的工作切换成低效度较高的全盘检索模式,进而显著拖累整体表现水平[^3]。 此外,值得注意的一点在于常规性的维护活动同样重要,像定期重建索引来保持它们处于良好状态等做法都可以间接促进此类难题得到缓解。 #### 特定场景下的注意事项 最后要强调一点就是并非所有的语法形式都适合进行类似的调整工作——特别是涉及到更新(UPDATE)或者删除(DELETE)这类带有嵌套子询问的操作时更是如此。由于技术上的局限性使得目前大多数主流关系型管理系统都无法对此类情况实施有效的自动重写处理机制,因此强烈不推荐在正式上线之前未经充分测试便贸然部署包含复杂子查询成分在内的修改指令序列[^4]。 ```sql -- 示例:为一张订单表建立覆盖索引以加速特定条件下的读取请求 CREATE INDEX idx_order_status_time ON orders (status, created_at); ``` 以上代码片段展示了一个简单的例子,它演示了如何为目标表格构建复合列组成的次级键值对组合对象实例化过程的一部分内容而已; 实际应用当中还需要考虑更多因素才能做出最恰当的选择方案出来. ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Survivor001

你可以相信我,如果你愿意的话

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值