【笔记】用户指南—诊断与优化—SQL审计与分析—日志分析

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: PolarDB-X支持SQL审计与分析功能,依托日志服务产品,提供强大的日志分析能力。本文将介绍常见场景的SQL日志分析语句及示例。

前提条件

开启SQL审计与分析功能。

注意事项

  • 相同地域下的所有PolarDB-X数据库的审计日志都会写入同一个日志服务的Logstore中,因此PolarDB-X的SQL审计与分析搜索框内会默认为您带上__topic__的过滤条件,保证您搜索到的SQL日志都属于同一地域下的PolarDB-X数据库。本文提供的所有查询语句,都需要在已有的__topic__过滤条件后追加使用。例如图中1部分的语句为默认过滤条件,序号2部分的语句为追加的过滤条件。
    3..png您可以单击原始日志各个字段后的详细内容,自动生成包含对应字段查询语句。

例如您可以单击sql_type后的Delete,查看所有包含Delete字段的SQL语句。4..png

快速定位SQL

您可以使用以下命令快速定位问题SQL。

  • 模糊搜索例如,您可以使用如下命令查询包含关键字为200003的SQL语句:
and sql: 200003
  • 字段搜索依赖预置的索引字段,PolarDB-X SQL审计还支持根据字段搜索。例如您可以使用如下命令查询DROP类型的SQL:
and sql_type:Drop
  • 多条件搜索您可以通过andor等关键字实现多条件的搜索。例如您可以使用如下命令查询针对id=200003行进行的所有DELETE语句:
and sql: 200003 and sql_type: Delete
  • 数值比较搜索索引字段中的affect_rowsresponse_time是数值类型,支持比较操作符。例如您可以使用如下命令查询response_time大于5秒的DROP语句:
and response_time > 5 and sql_type: Drop
  • 或者使用如下命令查询删除100行以上数据的SQL语句:
and affect_rows  > 100 and sql_type: Delete

SQL执行状况分析

您可以使用以下命令查看SQL执行状况。

  • SQL执行失败率您可以使用如下命令查询SQL执行的失败率:
| SELECT sum(case when fail = 1 then 1 else 0 end) * 1.0 / count(1) as fail_ratio
  • 查询结果如下图所示:

30.png

快速定位SQL

您可以使用以下命令快速定位问题SQL。

  • 模糊搜索例如,您可以使用如下命令查询包含关键字为200003的SQL语句:
and sql: 200003
  • 字段搜索依赖预置的索引字段,PolarDB-X SQL审计还支持根据字段搜索。例如您可以使用如下命令查询DROP类型的SQL:
and sql_type:Drop
  • 多条件搜索您可以通过andor等关键字实现多条件的搜索。例如您可以使用如下命令查询针对id=200003行进行的所有DELETE语句:
and sql: 200003 and sql_type: Delete
  • 数值比较搜索索引字段中的affect_rowsresponse_time是数值类型,支持比较操作符。例如您可以使用如下命令查询response_time大于5秒的DROP语句:
and response_time > 5 and sql_type: Drop
  • 或者使用如下命令查询删除100行以上数据的SQL语句:
and affect_rows  > 100 and sql_type: Delete

SQL执行状况分析

您可以使用以下命令查看SQL执行状况。

  • SQL执行失败率您可以使用如下命令查询SQL执行的失败率:
| SELECT sum(case when fail = 1 then 1 else 0 end) * 1.0 / count(1) as fail_ratio
  • 查询结果如下图所示:

1.png

高代价SQL模板Top 10

在大多数应用中,SQL通常基于若干模板动态生成的,只是参数不同。您可以使用如下命令通过模板ID找到应用中高代价的SQL模板:


| SELECT sql_code as "SQL模板ID", round(total_time * 1.0 /sum(total_time) over() * 100, 2) as "总体耗时比例(%)" ,execute_times as "执行次数", round(avg_time) as "平均执行时间",round(avg_rows) as "平均影响行数", CASE WHEN length(sql) > 200 THEN  concat(substr(sql, 1, 200), '......') ELSE trim(lpad(sql, 200, ' ')) end as "样例SQL" FROM  (SELECT sql_code, count(1) as execute_times, sum(response_time) as total_time, avg(response_time) as avg_time, avg(affect_rows) as avg_rows, arbitrary(sql) as sql FROM log GROUP BY sql_code) ORDER BY "总体耗时比例(%)" desc limit 10

统计结果中包括SQL模板ID,该模板SQL占总体SQL的耗时比例、执行次数、平均执行时间、平均影响行数以及样例SQL等信息。2.png


  • 说明
    上述查询是按照总体耗时比例%排序,您也可以根据平均执行时间执行次数进行排序帮助排查问题。
  • 事务平均执行时长对于相同事务内的SQL,预置的trace_id字段前缀相同,后缀为'-' + 序号;非事务的SQL的trace_id中则不包含'-'。因此,您可以使用如下命令对事务SQL的性能进行相关分析。说明由于事务分析涉及前缀匹配操作,查询效率会低于其它类型的查询操作。
    • 查询事务的平均执行耗时您可以使用如下语句查询事务的平均执行耗时:
| SELECT  sum(response_time) / COUNT(DISTINCT substr(trace_id, 1, strpos(trace_id, '-') - 1)) where strpos(trace_id, '-') > 0
    • 慢事务Top 10您可以按照事务的执行时间排序查询慢事务的列表:
| SELECT substr(trace_id, 1, strpos(trace_id, '-') - 1) as "事务ID" , sum(response_time) as "事务耗时" where strpos(trace_id, '-') > 0 GROUP BY substr(trace_id, 1, strpos(trace_id, '-') - 1) ORDER BY "事务耗时" DESC LIMIT 10
    • 在此基础上,您可以使用如下命令,根据查到的慢事务ID搜索该事务下的所有SQL用于分析执行慢的具体原因:
and trace_id: db3226a20402000*
    • 大批量操作事务Top 10您可以使用如下命令按照事务内SQL影响的行数排序,查询大批量操作的事务列表:
| SELECT substr(trace_id, 1, strpos(trace_id, '-') - 1) as  "事务ID" , sum(affect_rows) as "影响行数" where strpos(trace_id, '-') > 0 GROUP BY substr(trace_id, 1, strpos(trace_id, '-') - 1) ORDER BY "影响行数" DESC LIMIT 10

SQL安全性分析

您可以使用以下命令查看SQL安全性分析情况。

  • 错误SQL类型分布您可以使用如下命令查看错误SQL类型分布:
and fail > 0 | select sql_type, count(1) as "错误次数" group by sql_type
  • 高危SQL列表PolarDB-X 2.0中的高危SQL是指DROP或TRUNCATE类型的SQL(您也可以根据业务需求增加更多条件自定义高危SQL)。
    您可以使用如下命令查询包含DROP或TRUNCATE类型的SQL列表:
and sql_type: Drop OR sql_type: Truncate
  • 大批量删除SQL列表您可以使用如下命令大批量删除SQL列表:
and affect_rows > 100 and sql_type: Delete | SELECT date_format(from_unixtime(__time__), '%m/%d %H:%i:%s') as time,
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
176
分享
相关文章
MySQL进阶突击系列(07) 她气鼓鼓递来一条SQL | 怎么看执行计划、SQL怎么优化?
在日常研发工作当中,系统性能优化,从大的方面来看主要涉及基础平台优化、业务系统性能优化、数据库优化。面对数据库优化,除了DBA在集群性能、服务器调优需要投入精力,我们研发需要负责业务SQL执行优化。当业务数据量达到一定规模后,SQL执行效率可能就会出现瓶颈,影响系统业务响应。掌握如何判断SQL执行慢、以及如何分析SQL执行计划、优化SQL的技能,在工作中解决SQL性能问题显得非常关键。
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
基于SQL Server / MySQL进行百万条数据过滤优化方案
对百万级别数据进行高效过滤查询,需要综合使用索引、查询优化、表分区、统计信息和视图等技术手段。通过合理的数据库设计和查询优化,可以显著提升查询性能,确保系统的高效稳定运行。
57 9
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
57 3
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
1458 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
113 9
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
146 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
Tomcat log日志解析
理解和解析Tomcat日志文件对于诊断和解决Web应用中的问题至关重要。通过分析 `catalina.out`、`localhost.log`、`localhost_access_log.*.txt`、`manager.log`和 `host-manager.log`等日志文件,可以快速定位和解决问题,确保Tomcat服务器的稳定运行。掌握这些日志解析技巧,可以显著提高运维和开发效率。
78 13
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
48 5
图解MySQL【日志】——Redo Log

热门文章

最新文章