前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >源码解析丨一次慢SQL排查之旅

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

作者头像
老叶茶馆
发布2024-04-28 16:54:35
640
发布2024-04-28 16:54:35
举报

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=; delete from info where id < ;

环境信息

配置参数ip172.17.x.xhostnamedevmemory16Gcpu8CGreatSQL version8.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)
    • log_slow_do // 开始写入
    • log_slow
    • write_slow
    • slow_log_write
    • lex->m_sql_cmd->execute // 常见的CRUD操作
    • thd->enable_slow_log = true // 初始化enable_slow_log为true
    • thd->set_time // 设置开始时间
    • dispatch_sql_command
    • parse_sql // 语法解析
    • mysql_execute_command // 执行SQL
    • thd->update_slow_query_status // 判断是否达到慢日志阈值。若为慢查询,则更新thd的server_status状态,为写slow_log作准备
    • log_slow_statement
    • log_slow_applicable // 判断是否写入慢日志

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

  • 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) session1session2begin; 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秒(简单说:【会】包含锁等待耗时)。 P.S,八怪老师也写过一篇这方面的文章:MySQL:8.0.28及其之后慢查询记录算法的重大变化,推荐也看看。

Enjoy GreatSQL :)

本文参与?腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2024-04-23,如有侵权请联系?cloudcommunity@tencent.com 删除

本文分享自 老叶茶馆 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与?腾讯云自媒体分享计划? ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 当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=; delete from info where id < ;
    • 环境信息
    • 配置参数ip172.17.x.xhostnamedevmemory16Gcpu8CGreatSQL version8.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)
        • 根本原因
          • 一、慢日志写入大致流程
        • 二、判断是否达到慢日志阈值
        相关产品与服务
        云数据库 MySQL
        腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
        http://www.vxiaotou.com