记录一次长时间未提交事务造成的慢SQL

目录

问题描述

问题分析

1、了解前后信息

2、分析执行计划

3、分析生产环境系统负载

4、分析数据库性能

5、初步锁定根因为长时间未提交事务导致

6、最终根因定位

7、原理分析


问题描述:

开发反馈执行某条select语句的时候,生产环境和测试环境耗时相差非常大,生产耗时要18S,测试环境耗时不到1秒钟。

问题分析:

1、了解前后信息

a、该SQL是近期新上的

b、生产执行耗时要18S,测试环境耗时不到1秒钟

c、该SQL属于业务人员点击页面发起的查询

d、普通select语句

2、分析执行计划

比较了生产和测试环境的执行计划,执行计划完全相同,比较数据量也相差不大,因此排除执行计划不同导致的耗时差异。

3、分析生产环境系统负载

检查生产环境io、cpu、内存负载情况,系统负载不高,未发现瓶颈。

4、分析数据库性能

a、计算缓冲池命中率,可以达到99.99%,说明数据库内存配置合理

b、检查数据库会话信息,活跃连接数量、连接数使用率不高,未发现瓶颈

c、检查数据库异常会话,依次检查数据库是否有锁等待、长时间未提交事务,发现数据库有一条insert into select 的SQL语句已经执行超过半个月还没有提交,该insert语句中的select子查询为多表关联,其中一张表与耗时慢的SQL涉及的表相同,故怀疑耗时慢的select语句是受到长时间未提交事务影响。

d、查看该慢SQL在主库和从库的执行计划、耗时,发现主从执行计划相同,主库执行耗时18S,从库执行耗时11S,从库执行明显比主库快。

5、初步锁定根因为长时间未提交事务导致

a、手动将长时间未提交事务杀掉

b、再次查看该慢SQL在主库的耗时,发现耗时已经降到11S,和从库一致。至此,已经解决了主从执行耗时不一致的问题。还剩下一个问题,就是生产和测试执行耗时不同。

c、继续分析慢SQL,该select语句用到了group by和order by,并且生产和测试都用到了file sort,去掉order by,发现测试用于排序的行记录数比生产少很多,测试返回给排序的行记录数为几百条,而生产上返回给排序的行记录是几百万行,故生产耗时比测试多也是意料之中。毕竟,测试数据是做过脱敏处理,并且测试和生成数据也有区别。

6、最终根因定位

即长时间未提交事务导致主库对应的select语句性能下降,解决方案为杀掉长时间未提交的事务。

7、原理分析

给大家留个思考,我们下次再展开讨论,大家可以在评论区发表自己的看法。

相关推荐
风哥2号3 小时前
数据库教程FGMT52‑PostgreSQL用户权限与安全管理
数据库·postgresql
风哥2号10 小时前
数据库教程FGMT27‑MySQL数据库基础知识与体系架构
数据库·mysql
YangYang9YangYan11 小时前
2026 校招商品分析岗位 JD 拆解,核心指标、工具与面试考点
大数据·数据库·数据分析
西安栈上月明软件科技12 小时前
从业务黑话到本体图谱:OAG本体建模五步法(西安老系统AI化改造实战)
数据库·人工智能·架构
anxiao_m12 小时前
跨云跨机房大数据迁移怎么选?不同场景工具适配指南
数据库·云启快传
风哥2号14 小时前
数据库教程FGMT43‑MySQL性能分析与优化调整
数据库·mysql
随身数智备忘录14 小时前
财务数据分析如何与业务场景结合?财务数据分析如何从数出有据到数出有用?
数据库
这个DBA有点耶15 小时前
数据库教程:从零基础到实战的完整学习路径(2026版)
数据库·程序员·代码规范
forestsea16 小时前
从零构建 Java 智能体 RAG 系统:Milvus 向量数据库实战指南
java·数据库·milvus
默 语16 小时前
Java新手入门:从零开始安装JDK并配置环境变量
java·开发语言·python·mysql·group by·1024程序员节·数据去重