源码解析丨一次慢SQL排查

Postgres慢SQL排查手段 文章目录一、慢SQL日志记录1.1 相关参数设置1.2 查看相关慢SQL日子二、pg_stat_statements插件2.1 插件安装三、排查手段3.1 查看当前会话执行情况3.2 通过pg_stat_statements查看TOP SQL3.3 kill执行效率低下的堆积会话 一、慢SQL日志记录 1.1 相关参数设置 -- 基本日志采集开启参数 log_destination = 'stderr' # Valid values are combinations of logg 阅读详情

当long_query_time=1时(表info的id为主键),出现下面的慢日志,可能会让你吃惊

# Time: 2024-01-28T22:52:24.500491+08:00
# User@Host: root[root] @  [127.0.0.1]  Id:     8
# Query_time: 7.760787  Lock_time: 7.757456 Rows_sent: 0  Rows_examined: 0
use apple;
SET timestamp=1706453536;
delete from info where id < 10;

环境信息

配置参数
ip172.17.137.12
hostnamedev
memory16G
cpu8C
MySQL versionGreatSQL 8.0.26

慢查询相关参数

greatsql> select * from performance_schema.global_variables where variable_name in('slow_query_log','log_output','slow_query_log_file','long_query_time','log_queries_not_using_indexes','log_slow_admin_statements','min_examined_row_limit','log_throttle_queries_not_using_indexes') order by variable_name;
+----------------------------------------+-------------------------------------+
| VARIABLE_NAME                          | VARIABLE_VALUE                      |
+----------------------------------------+-------------------------------------+
| log_output                             | FILE                                |
| log_queries_not_using_indexes          | OFF                                 |
| log_slow_admin_statements              | OFF                                 |
| log_throttle_queries_not_using_indexes | 0                                   |
| long_query_time                        | 1.000000                            |
| min_examined_row_limit                 | 0                                   |
| slow_query_log                         | ON                                  |
| slow_query_log_file                    | /root/local/8026/log/slow.log       |
+----------------------------------------+-------------------------------------+
8 rows in set (10.49 sec)
  • slow_query_log:慢日志开关

  • log_output:慢日志存储方式,FILE或TABLE

  • long_query_time:慢日志阈值

  • min_examined_row_limit:设置慢SQL的最小examined扫描行数,建议设置为0,因为有bug:https://bugs.mysql.com/bug.php?id=110804

  • log_queries_not_using_indexes:不使用索引的慢查询日志是否记录到索引

  • log_slow_admin_statements:在写入慢速查询日志的语句中包含慢速管理语句(create index,drop index,alter table,analyze table,check table,optimize table,repair table)默认是不会记录的

  • log_throttle_queries_not_using_indexes:用于限制每分钟输出未使用索引的日志数量。每分钟允许记录到slow log的且未使用索引的sql语句次数,配合long_queries_not_using_indexes开启使用。

  • log_slow_slave_statements:默认OFF,是否开启主从复制中从库的慢查询

根本原因

一、慢日志写入大致流程

  • dispatch_command(thd)

    • thd->enable_slow_log = true // 初始化enable_slow_log为true

    • thd->set_time // 设置开始时间

    • dispatch_sql_command

    • parse_sql // 语法解析

    • mysql_execute_command // 执行SQL

      • lex->m_sql_cmd->execute // 常见的CRUD操作
    • thd->update_slow_query_status // 判断是否达到慢日志阈值。若为慢查询,则更新thd的server_status状态,为写slow_log作准备

    • log_slow_statement

    • log_slow_applicable // 判断是否写入慢日志

      • log_slow_do // 开始写入

        • slow_log_write

          • log_slow

          • write_slow

二、判断是否达到慢日志阈值

  • 8.0.26版本的慢日志判断标准
void THD::update_slow_query_status() {
  if (my_micro_time() > utime_after_lock + variables.long_query_time)
    server_status | = SERVER_QUERY_WAS_SLOW;
}
// my_micro_time() 获取当前系统时间点,单位为微妙
// utime_after_lock 为MDL LOCK和row lock等待时间后的时间点,单位为微妙
// variables.long_query_time 慢日志阈值long_query_time * 1000000 ,单位为微妙
// 等价于:my_micro_time() - utime_after_lock  > variables.long_query_time
// 不包含锁等待时间
  • 8.0.32版本的慢日志判断标准(8.0.28开始)
void THD::update_slow_query_status() {
  if (my_micro_time() > start_utime + variables.long_query_time)
    server_status | = SERVER_QUERY_WAS_SLOW;
}
// 判别标准变成了:(语句执行结束的时间 - 语句开始执行时间) > 慢日志阈值
// my_micro_time() 当前系统时间点,单位为微妙
// start_utime:语句开始执行时间点,单位为微妙
// variables.long_query_time 慢日志阈值long_query_time * 1000000 ,单位为微妙
// 包含锁等待时间

从上面可以看出慢日志的判断标准发生了根本变化

举例说明

greatsql> select * from info;
+----+------+
| id | name |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  5 |    5 |
| 60 |    8 |
| 40 |   11 |
| 20 |   20 |
| 30 |   30 |
+----+------+
7 rows in set (0.05 sec)

greatsql> show create table info\G
*************************** 1. row ***************************
       Table: info
Create Table: CREATE TABLE `info` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` int NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.02 sec) 
session1session2
begin;
delete from info where id < 10;
delete from info where id < 10;
session1等待一段时间超过慢日志阈值long_query_time
rollback;

• 在8.0.26版本中,是不会记录session2中的delete from info where id < 10

• 在8.0.32版本中,会记录session2中的delete from info where id < 10

三、判断是否写入慢日志

void log_slow_statement(THD *thd,
                        struct System_status_var *query_start_status) {
  if (log_slow_applicable(thd)) log_slow_do(thd, query_start_status);
}


//----------------------------------------------------------------

bool log_slow_applicable(THD *thd) {
  DBUG_TRACE;

  /*
    The following should never be true with our current code base,
    but better to keep this here so we don't accidently try to log a
    statement in a trigger or stored function
  */
  if (unlikely(thd->in_sub_stmt)) return false;  // Don't set time for sub stmt

  if (unlikely(thd->killed == THD::KILL_CONNECTION)) return false;

  /*
    Do not log administrative statements unless the appropriate option is
    set.
  */
  if (thd->enable_slow_log && opt_slow_log) {
    bool warn_no_index =
        ((thd->server_status &
          (SERVER_QUERY_NO_INDEX_USED | SERVER_QUERY_NO_GOOD_INDEX_USED)) &&
         opt_log_queries_not_using_indexes &&
         !(sql_command_flags[thd->lex->sql_command] & CF_STATUS_COMMAND));
    bool log_this_query =
        ((thd->server_status & SERVER_QUERY_WAS_SLOW) || warn_no_index) &&
        (thd->get_examined_row_count() >=
         thd->variables.min_examined_row_limit);
    bool suppress_logging = log_throttle_qni.log(thd, warn_no_index);

    if (!suppress_logging && log_this_query) return true;
  }
  return false;
}
  • 若log_slow_applicable(thd)返回值为true,则执行log_slow_do(thd, query_start_status),写入慢日志

  • if (unlikely(thd->in_sub_stmt)) return false;if (unlikely(thd->killed == THD::KILL_CONNECTION)) return false;

​ a. 子查询,返回false

​ b. 被kill,返回false

​ c. 解析出错,返回false

​ d. 执行出错,返回false

  • warn_no_index 表示log_queries_not_using_indexes开启且(未使用索引或未使用最优索引)

    • thd->server_status 该线程状态

    • SERVER_QUERY_NO_INDEX_USED 表示未使用索引

    • SERVER_QUERY_NO_GOOD_INDEX_USED 表示未使用最优索引

    • opt_log_queries_not_using_indexes 表示log_queries_not_using_indexes参数的值,默认OFF

  • !(sql_command_flags[thd->lex->sql_command] & CF_STATUS_COMMAND))表示该语句不是SHOW相关的命令。CF_STATUS_COMMAND常量表示执行的命令为show相关的命令。

  • log_this_query = ((thd->server_status & SERVER_QUERY_WAS_SLOW) || warn_no_index) && (thd->get_examined_row_count() >=thd->variables.min_examined_row_limit);

    • (thd->server_status & SERVER_QUERY_WAS_SLOW) 表示该SQL为慢查询

    • (thd->get_examined_row_count() >=thd->variables.min_examined_row_limit) 表示SQL的扫描数据行数不小于参数min_examined_row_limit 的值,默认为0

  • log_throttle_qni.log(thd, warn_no_index) 表示用来计算该条未使用索引的SQL是否需要写入到slow log,计算需要使用到参数log_throttle_queries_not_using_indexes , 该参数表明允许每分钟写入到slow log中的未使用索引的SQL的数量,默认值为0,表示不限制

按照线上配置

  • log_throttle_queries_not_using_indexes = 0

  • log_queries_not_using_indexes = OFF

  • log_slow_admin_statements = OFF

  • min_examined_row_limit = 0

  • slow_query_log = ON

  • long_query_time = 1.000000

那么在GreatSQL-8.0.26中,是否写入到慢日志中,取决于thd->server_status & SERVER_QUERY_WAS_SLOW,即SQL执行总耗时-SQL锁等待耗时>1秒

那么在GreatSQL-8.0.32中,是否写入到慢日志中,取决于thd->server_status & SERVER_QUERY_WAS_SLOW,即SQL执行总耗时>1秒


Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

image

社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html

(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)

技术交流群:

微信&QQ群:

QQ群:533341697

微信群:添加GreatSQL社区助手(微信号:wanlidbc )好友,待社区助手拉您进群。

解决 ShardingSphere 第一次请求慢的喷血日子 学习起因:整合了 ShardingSphere 的项目第一次访问的时候很慢,第二次访问的时候速度就快了,然后老大让我去一探究竟,然后下面就是探索的血泪史。 通过 Arthas 生成火焰图,定位到慢在ShardingSphere sql 解析,第一次请求使用 ANTLR 解析 SQL 耗时较长,而第二次请求由于缓存原因耗时很小 curl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar profiler s. 阅读详情

相关推荐

记一次spark源码的bug排查,顺便简单看一下spark sql底层引擎catalyst处理的流程

场景: hive中事先创建好分区表test_table_name,然后通过spark streaming任务处理数据,将rdd转为dataframe后写hive。 具体出错代码 val result = sparkSession.createDataFrame(rdd, schema) result.write.mode("append").format("hive").partitionBy...

knowfarhhy 2948

mysql query_time单位_深入mysql慢查询设置的详解

在web开发中,我们经常会写出一些SQL语句,一条糟糕的SQL语句可能让你的整个程序都非常慢,超过10秒一般用户就会选择关闭网页,如何优化 SQL语句将那些运行时间 比较长的SQL语句找出呢?(4)如果日志文件不想放在data目录,我们可以通过如下配置指定存放的目录及日志文件名:slow_query_log_file=file_name其中file_name就是你的存放日志的目录和文件名,在这里注意有的资料上可能是log-slow-queries=file_name,这个在mysql5.5版已经过时!

大鹏 5284

记一次CPU有规律飙高的线上问题排查过程

cpu问题排查过程

程序男的专栏 1781

MySQL性能优化--慢查询日志的使用

一、修改慢查询时间 数据库默认的long_query_time是10秒 但是,响应时间是毫秒级别的(应用服务器时间+网络时间+数据库时间) 所以,long_query_time应当设为1s 1、查看数据库默认的long_query_time show variables like ‘long_query_time’ 2、修改配置文件 long_query_time=1 3、在服务中重启mysql 4、再次查看long_query_time show variables like

波点兔的博客 1065

## 解Bug之路,记一次存储故障的排查过程

解Bug之路,记一次存储故障的排查过程 高可用真是一丝细节都不得马虎。平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查。今天,笔者就给大家带来一个存储偶发性故障的排查过程。 Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件。一直稳定运行,但应用最近确经常偶发连接建立不上的报错。报错如下: GetConnectionTimeOutException 而笔者中间件

javaAnPou的博客 521

【SpringBoot 4.x 第209节】线上接口变慢如何定位:慢 SQL、慢接口与线程池耗尽排查实战!

🏆 本文收录于 《滚雪球学 Spring Boot 4.x》 专栏。本专栏面向 有一定 Java 基础,但尚未系统学习 Spring Boot 的读者,采用“滚雪球式学习法”:先跑通、再理解、再重构、再上线,带你从第一个 Hello API 开始,逐步完成一个可部署、可监控、可扩展的后端项目。

**My Coding Family** 335

Slowlog中小于long_query_time时间设置的query

说到慢查询,有点老生常谈了,但是慢查询相关的有个参数可能会被很多人忽略。 log_queries_not_using_indexes 这个参数设置当查询没有使用索引的情况下,是否记录到slowlog中。 如果你使用的mysql版本大于5.6.5,也可以通过设置 log_throttle_queries_not_using_indexes 这个参数表示每分钟允许记录到slowlog且未使用索引的次数。默认值为0,标识没有限制。

Mr_Melody的专栏 5970

【SpringBoot 4.x 第129节】线上接口变慢如何定位:慢 SQL、慢接口、线程池耗尽

🏆 本文收录于 《滚雪球学 Spring Boot 4.x》 专栏。本专栏面向 有一定 Java 基础,但尚未系统学习 Spring Boot 的读者,采用“滚雪球式学习法”:先跑通、再理解、再重构、再上线,带你从第一个 Hello API 开始,逐步完成一个可部署、可监控、可扩展的后端项目。

**My Coding Family** 84

long_query怎么解决

设置参数,开启慢日志功能,得到耗时超过一定时间的sql (1)slow_query_log 这句是开启记录慢查询功能,slow_query_log=0关闭;slow_query_log=1开启(这个1可以不写) (2)long_query_time = 1 这句是记录超过1秒的SQL执行语句 ...

weixin_48193426的博客 1009

创新实训项目博客:基于LoRA的医疗大模型高效微调实战

预训练大语言模型(LLMs)虽然具备了广泛的知识和一定的通用能力,但在特定领域(如医疗)或特定任务(如遵循特定指令格式进行思考链推理)上,其表现往往不尽如人意。微调(Fine-tuning)能够使模型学习到特定领域的数据分布和任务模式,从而在目标任务上获得更好的性能,使其更贴合实际应用需求。使用Unsloth框架加载并以4-bit量化模型。基于数据集,构建了包含明确思考链引导的训练Prompt。配置了LoRA参数,并使用SFTTrainer在单张T4 GPU上对模型进行了高效微调。

m0_73556916的博客 1290

Opencv实战:答题卡自动识别与评分系统(附完整代码解析)

本文详细介绍了如何使用OpenCV实现答题卡自动识别与评分系统,包含完整的代码解析。通过图像预处理、边缘检测、透视变换和答案识别等关键技术,系统能够快速准确地完成阅卷工作,适用于学校考试、资格认证等多种场景,大幅提升工作效率。

weixin_33737134的博客 415

源码解析丨一次慢SQL排查之旅

* GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。当long_query_time=1时(表info的id为主键),出现下面的慢日志,可能会让你吃惊#Time:2024-01-28T22:52:24.500491+08:00 #User@Host:root[root]@[127.0.0.1]Id:8 #Query_time:7.7607...

老叶茶馆 244

SGLang HiCache实战:手把手教你配置KV Cache Offload,让大模型推理成本直降84%

本文详细介绍了SGLang HiCache在KV Cache Offload配置与调优中的实战应用,通过多级存储架构和智能卸载策略,显著降低大模型推理成本达84%。文章涵盖HiCache架构优势、环境配置、高级调优策略及生产环境最佳实践,帮助开发者优化GPU显存使用,提升并发处理能力。

weixin_29044713的博客 462

PostgreSQL 排查慢 SQL

所谓慢 SQL是指在数据库中执行时间超过指定阈值的语句。慢查询太多,对于业务而言,是有很大风险的,可能随时都会因为某种原因而被触发,并且根据我们的经验,数据库最常出现的问题,都是因为慢查询导致数据库慢了,进而导致整个实例 “雪崩” 从而导致线上故障。本篇文章将介绍 PostgreSQL 慢 SQL 如何定位排查。

分享既学习 4634

【Cadence】PSS+PSTB/PAC仿真在开关电源稳定性分析中的关键应用

本文深入探讨了Cadence仿真工具中PSS+PSTB/PAC方法在开关电源稳定性分析中的关键应用。针对开关电源作为时变非线性系统的特性,传统STB仿真方法会失效。文章详细阐述了如何通过PSS分析找到周期稳态,并在此基础上利用PSTB或PAC进行精确的环路增益和小信号频响分析,为电源设计提供可靠的稳定性评估与补偿网络设计依据。

weixin_29276847的博客 527

软件设计师---计算机系统

软件设计师---计算机系统

我从不打没有准备的仗! 3万+

PostgreSQL 慢 SQL 排查

所谓慢SQL 是指在数据库中执行时间超过指定阈值的语句。慢查询太多,对于业务而言,是有很大风险的,可能随时都会因为某种原因而被触发,并且根据我们的经验,数据库最常出现的问题,都是因为慢查询导致数据库慢了,进而导致整个实例 “雪崩” 从而导致线上故障。本篇文章将介绍 PostgreSQL 慢 SQL 如何定位排查。

2063

Python 爬虫实战:科研数据库学术论文数据抓取

在科研工作中,学术论文是获取前沿知识和研究方法的重要资源。然而,手动从科研数据库中查找和整理论文信息往往耗时费力。幸运的是,Python 爬虫技术可以自动化这一过程,帮助我们高效地抓取和管理学术论文数据。本文将详细介绍如何使用 Python 爬虫技术抓取科研数据库中的学术论文数据,并进行全字段提取和文献管理,助力科研工作。

u014481728的博客 945

记一次现场慢问题的排查

上周正在调休从准老丈人家回来的时候,同事说有个项目点评级特别慢,造成系统卡死,希望我能去现场看看到底是什么情况。 从项目点发来的日志来看,在计算完一个积分要素,计算下一个积分要素竟然需要三分钟之后才进行。不知道中间到底发生了什么。 带着疑问,周一一早到项目点查看,如项目点反馈,排除页面加载本来就慢等这些原本就存在的问题(公司有安排人手在修改这部分),评级流程确实是要比公司慢一些。之后打开日志,...

xuwenzhong1994的博客 757

Roboflow 与 YOLOv11 数据集全流程:从获取到训练,让你数据无忧

上传图像:点击“Upload”按钮,批量上传本地图像(支持 JPG、PNG 格式,单张最大 10MB)。智能标注:利用 Roboflow 的“Auto-Annotate”功能,基于预训练模型自动生成标注,再手动微调,标注效率提升 70%。格式导出:标注完成后,同样选择“YOLOv11”格式导出,流程与公开数据集一致。

m0_71589036的博客 272

基于Simulink进行光伏逆变器效率分析的仿真建模

特点能量转换:将光伏电池板产生的直流电转换为交流电。效率评估:分析逆变器在不同负载条件和环境条件下的效率。动态特性:考虑温度、光照强度等外部因素对逆变器效率的影响。挑战精确建模:准确地模拟光伏电池板、逆变器及其交互的动力学过程。多因素考量:需要同时考虑输入电压、电流、温度、光照强度等多种因素对逆变器效率的影响。集成度:需要与其他系统(如最大功率点跟踪MPPT算法、电网连接等)无缝集成,以实现全面的系统分析。首先明确要模拟的任务内容。输入条件(如光照强度、温度等)。

amy_mhd的博客 142

SpringBoot——开启Druid监控统计功能(SQL监控、慢SQL记录、Spring监控、去广告)

参考: github#Druid源码 github#druid-spring-boot-starter源码 Druid Wiki springboot#data-properties 参考博客 SpringBoot+Druid+mybatis+log4j2+mysql8 1 基本概念 Druid 是Java语言中最好的数据库连接池。 虽然 HikariCP 的速度稍快,但是,Druid能够提供强大的监控和扩展功能,也是阿里巴巴的开源项目。 Druid是阿里巴巴开发的号称为监控而生的数据库连接池,在功能、性

weixin_44730681的博客 2万+

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

纯干货:数据库连接耗时慢原因排查

针对这类高访问的项目,任何不留神的地方都可能会引起连锁反应导致瓶颈,本次是针对此次排查提供一些我探索的方法。

长沙要起风了、 4217

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

MyBatis核心源码解析 从SqlSession到Mapper接口的绑定过程

摘要:本文深度解析MyBatis框架的核心原理与最佳实践。从架构总览、SqlSession创建机制到Mapper动态代理实现,详细剖析了SQL执行链路、缓存机制和插件原理。通过源码分析揭示MyBatis内部工作原理,包括Configuration加载、Executor调度和StatementHandler执行过程。针对常见性能问题提供优化方案,如批量操作、分页查询和缓存使用技巧。最后总结企业级开发中的"MyBatis军规",包括SQL编写规范、缓存策略和监控方案,帮助开发者规避典型陷阱,

七夜zippoe的博客 2150

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

线上故障 | 一条 SQL引发的血案

欢迎关注公众号【sharedCode】致力于主流中间件的源码分析, 可以直接与我联系 事故现场 202-11-19 系统接收到大量的超时告警, 同时业务群里面也有很多客户反馈服务不可用。 开始排查 首先上grafana上面查看整体的服务状态, 从图中可以看出一点问题来,CPU几乎没有波动, tomcat线程数急剧上升, 系统的ops急剧下降。 这种是比较典型的资源阻塞类问题,为了印证这个想法,我们再看下当时的系统的GC情况 从上面的GC情况下,我们可以看出来,GC还是比较平稳的,整体的停顿市场也.

sharedCode源码交流 5432
上一篇: 故障解析丨一次死锁问题的解决
下一篇: 工具分享丨分析GreatSQL Binglog神器
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值