使用statistics profile分析query的实际运行情况

最新推荐文章于 2024-12-17 18:14:27 发布
最新推荐文章于 2024-12-17 18:14:27 发布
阅读量874 收藏
点赞数
分类专栏： SQL Server数据库
本文介绍如何使用statistics_profile记录SQL查询的实际运行过程及统计信息，包括开启存储过程的执行统计和解决因未定义临时表导致的执行计划查看错误。

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

使用statistics profile可以记录query实际运行的详细过程和统计信息。例如下面SQL可以记录存储过程每一步的运行情况和执行计划： 


SET STATISTICS PROFILE ON
GO

[dbo].[YouStoredProcedure]

另外如果存储过程中使用了没有事先定义的临时表时，查看执行计划会报错。此时将执行计划关掉就可以了。

SET SHOWPLAN_TEXT OFF
GO

SET STATISTICS PROFILE ON
GO

[dbo].[YouStoredProcedure]


MySQL Show Profile分析
m0_62143653的博客
03-10 445
MySQL
MySQL使用show profile调优
Lxn2zh的博客
01-24 615
有时候使用explain执行计划发现其实是命中了索引的，但是还是很慢，此时可以使用profile功能，show profile是mysql提供的可以用来分析当前会话中语句执行的资源消耗情况，如CPU、IO、IPC、SWAP以及发生的PAGE FAULTS等，可以用于SQL调优的测量。来查询之外，还可以使用information_schema.PROFILING表来进行查询，且可以进行排序等操作。source 显示Source_function、Source_file、Source_line相关开销。
set statistics profile on实例
weixin_33843947的博客
08-08 181
set statistics profile on实例   1、SQL语句实例   SQL 代码   复制 SET STATISTICS PROFILE ON GO SELECT COUNT(b.[SalesOrderID]) FROM [dbo].[SalesOrderHeader_test] a INNER JOIN [dbo].[SalesOrderDetail_test] ...
SQL Server 调优：set statistics profile on
weixin_30836759的博客
04-14 129
进行set statistics profile on 设置后 将会返回执行计划表，通过该表，可以理解语句执行的过程，了解SQL Server是否选择了正确的执行计划，进而确定调优方向！ 1、返回表字段描述: Rows:执行计划每一步返回的实际行数 Executes：执行计划每一步执行的次数 StmtText：执行计划的具体内容，每一步都有自己的执行内容，且有结果返回，当然每执行一次，都会...
SQL Server读懂语句运行的统计信息 SET STATISTICS TIME IO PROFILE ON
dingshen2767的博客
01-13 451
SQL Server读懂语句运行的统计信息 SET STATISTICS TIME IO PROFILE ON 对于语句的运行，除了执行计划本身，还有一些其他因素要考虑，例如语句的编译时间、执行时间、做了多少次磁盘读等。 如果DBA能够把问题语句单独测试运行，可以在运行前打开下面这三个开关，收集语句运行的统计信息。 这些信息对分析问题很有价值。 1 SET STATISTIC...
set statistics profile on统计字段说明
whazhl的专栏
09-15 1267
 一、统计返回的字段说明   Rows 执行计划的每一步返回的实际行数   Executes 执行计划的每一步被运行了多少次   StmtText 执行计划的具体内容。执行计划以一棵树的形式显示。每一行都是运行的一步，都会有结果集返回，也都会有自己的cost   EstimateRows SQLSERVER根据表格上的统计信息，预估的每一步的返回行数。在分析执行计划时
set statistics profile on的用法
cxzhq2002的杂记
11-09 1353
本文导读：该语句执行后，除了返回常规结果集外，还返回每个语句的执行信息。SET STATISTICS PROFILE ON 输出还包含有关各种操作符处理的实际行数和操作符的实际执行数。下面介绍set statistics profile on的用法 一、SET STATISTICS PROFILE ON的用处 返回语句的执行计划，以及语句运行在每一步的实际返回行数统计。通过这个结果
MySQL 性能分析之Profile
2401_83616384的博客
03-16 1073
MySQL提供了一个非常有用的诊断工具，称为“Profile”，用于分析SQL语句的执行情况，帮助开发者优化查询。Profile可以给出查询执行的详细信息，比如每个阶段花费的时间等。
利用impala query profile解决性能问题（一）Impala plan and profile
weixin_44893236的博客
12-17 922
Impala 的执行计划是Impala根据客户端提交的 SQL 生成的一系列操作节点图，不同的操作对应不同的 PlanNode, 如：‌ScanNode、SortNode、 AggregationNode， HashJoinNode、‌LimitNode、‌UnionNode、ExchangeNode 等等。通过分区裁剪、谓词下推、运行时过滤器等方法，尽可能减少不必要的工作使用 DN 块元数据最大化扫描位置。最小化数据移动（优化连接顺序，选择更好的连接策略）
高性能MySQL学习三(性能优化、pt-query-digest的使用、SHOW PROFILE分析)
yyyxxxs的博客
08-16 344
1、性能优化简介 首先，我们将性能定义为完成某件任务所需要的时间，简言之，性能即响应时间。 所谓性能优化就是在一定的工作负载下尽可能地降低响应时间。（吞吐量是单位时间内的查询数量，所以性能优化也可以说成提升吞吐量） 接着，要知道的一点是，有效测量才能有效优化。 通过性能剖析进行有效地性能优化： 2、通过pt-query-digest进行性能剖析 (1)pt-query-digest安装 官网安...
SQLServerExecutionTimes
07-25
查看一个SP的效率一般用 SET STATISTICS TIME ON SET STATISTICS PROFILE ON SET STATISTICS IO ON 三个开关语句 看它的 时间 执行计划 IO 但是一般时间有很多 如： SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 16 ms, elapsed time = 5 ms. 而我们需要是总的时间 这个程序就是把这些时间累加起来
SET STATISTICS IO ON的使用
伴老
05-19 3982
SET STATISTICS IO 使 SQL Server 显示有关由 Transact-SQL 语句生成的磁盘活动量的信息。语法：SET STATISTICS IO { ON | OFF }注：如果 STATISTICS IO 为 ON，则显示统计信息，直到遇到OFF时不显示统计信息。例如：SET STATISTICS IO ONselect * from _Sale_Bill_NewSET
mysql profile query_MySQL Query Profile 简单使用[转载]
weixin_39870700的博客
01-31 97
MySQL Query Profile MySQL 5.0.37 以上开始支持 MySQL Query Profiler, 可以查询到此 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 System lock, Table lock 花多少时间等等.详细可以参见官方文档：Using the New MySQL Query Profiler启动mysql> set...
mysql profile query_MySQL Query Profile 简单使用
weixin_33019803的博客
01-31 148
MySQL Query Profile MySQL 5.0.37 以上开始支持 MySQL Query Profiler, 可以查询到此 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 System lock, Table lock 花多少时间等等.详细可以参见官方文档：Using the New MySQL Query Profiler启动mysql> set...
mysql query profile_Mysql调优之profile详解
weixin_30951515的博客
01-19 203
查看自己的mysql版本：mysql> select version();+------------+| version() |+------------+| 5.6.35-log |+------------+查看是否开启profile功能(profiling=on代表开启)：mysql> show variables like '%profil%';+--------------...
带你走进Impala query profile第二篇
Allenzyg的博客
10-13 914
带你走进Impala query profile第二篇 在上一篇文章中（https://blog.youkuaiyun.com/Allenzyg/article/details/107105335），我们介绍了Impala query profie的概要部分，在本篇文章我们介绍Profile的查询计划（Query Plan）和执行概要（Execution Summary）部分。 Profile的查询计划和执行概要如下所示： Query Runtime Profile: Query (id=2945
SQL Server: 利用 SET STATISTICS IO 和 SET STATISTICS TIME 对T-SQL语句进行性能分析
辛亚平的专栏
06-21 5270
我们可以用 SET STATISTICS IO 和 SET STATISTICS TIME 对T-SQL语句进行性能分析。 方法如下： 在SQL Server查询分析器里面，执行： SET STATISTICS profile ON SET STATISTICS io ON SET STATISTICS time ON GO -- // The SQL statement t
SQL Server 性能优化 SQL Server Profiler 数据库引擎优化顾问
KingCruel的专栏
03-05 2214
1、查看执行时间和cpu，显示分析、编译和执行各语句所需的毫秒数。 -- 语法 --set statistics time { on | off } -- 实例 set statistics time on go select * from sys_user go set statistics time off go 执行后在【消息】里可以看到 2、查看查询对I/O的操作情况 -- 语法 --set statistics io { on | off } -- 实例 set statisti
show profile 显示executing
最新发布
07-18
<think>我们正在讨论MySQL的show profile功能，特别是其中的"executing"状态。用户可能遇到了SQL执行性能问题，并希望通过show profile分析来找出瓶颈。 根据引用内容，show profile可以显示SQL执行过程中各个阶段的资源消耗情况，包括时间、CPU、内存等。 问题：用户询问show profile中"executing"状态的含义及优化方法。 步骤： 1. 解释"executing"状态的含义：在show profile的输出中，"executing"状态表示MySQL服务器正在执行查询（即实际处理数据）的阶段。 这个阶段通常包括数据的读取、连接、排序、聚合等操作。 2. 分析"executing"状态耗时过长的可能原因： - 复杂查询：涉及多表连接、子查询、聚合函数等。 - 数据量过大：需要处理的数据行数非常多。 - 索引使用不当：没有使用索引或索引失效，导致全表扫描。 - 锁争用：查询过程中可能遇到锁（如表锁、行锁）等待，但注意，锁等待通常会有其他状态（如Sending data）而不是executing。 - 硬件资源瓶颈：CPU、内存或磁盘I/O性能不足。 3. 优化方法： - 使用EXPLAIN分析查询计划，查看是否使用了合适的索引，避免全表扫描。 - 优化查询语句，例如避免使用SELECT *，只选择需要的列；将复杂的查询拆分成多个简单查询；避免在WHERE子句中使用函数或表达式导致索引失效。 - 考虑增加合适的索引，特别是对连接键、WHERE条件中的列和排序/分组列。 - 如果数据量太大，考虑分页查询或限制结果集。 - 调整服务器配置，如增加缓冲池大小（innodb_buffer_pool_size）等。 - 如果发现是锁争用问题，可以尝试改变事务隔离级别或优化事务逻辑。 4. 使用show profile进行诊断的步骤（根据引用）： a. 开启profiling：SET profiling = 'ON'; b. 执行SQL语句； c. 查看最近查询的ID列表：SHOW profiles; d. 查看具体某条查询的详细耗时分布：SHOW profile for query [query_id]; 或者更详细地查看CPU和内存：SHOW profile cpu, memory for query [query_id]; 5. 注意：在show profile的输出中，除了executing状态，还有其他状态（如Sending data、Copying to tmp table等）也可能耗时较长，需要综合判断。 6. 引用中提到的其他重要信息： - 引用[5]指出，如果出现“converting HEAP to MyISAM”或“Copying to tmp table on disk”，说明内存不足，需要优化查询或增加内存。 - 引用[4]说明profile可以记录资源开销，包括IO、上下文切换、CPU、内存等。 因此，在回答中，我们需要涵盖以上内容，并给出具体建议。 回答结构： 1. 解释"executing"状态 2. 可能原因 3. 优化方法 4. 诊断步骤示例 5. 注意事项</think>### MySQL `show profile executing` 状态详解与优化指南 #### 一、`executing` 状态的含义 在 MySQL 的 `show profile` 输出中，**`executing` 状态表示 SQL 语句在服务器线程中的实际执行阶段**，具体包含： 1. **核心计算过程**：WHERE 条件过滤、JOIN 操作、聚合函数计算等 2. **数据检索操作**：从存储引擎读取数据行（即使已使用索引） 3. **内存数据处理**：排序（ORDER BY）、分组（GROUP BY）、临时表创建等 4. **执行耗时占比**：通常占总查询时间的 60%-90%，是性能优化的关键点[^1][^2] ```sql -- 示例诊断输出（重点关注 executing 行） SHOW PROFILE FOR QUERY 2; +--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000065 | | checking permissions | 0.000010 | | Opening tables | 0.000034 | | init | 0.000031 | | System lock | 0.000019 | | optimizing | 0.000016 | | statistics | 0.000073 | | preparing | 0.000032 | | executing | 1.283471 | <-- 核心执行阶段 | Sending data | 0.000153 | | end | 0.000014 | | query end | 0.000011 | | closing tables | 0.000014 | | freeing items | 0.000028 | | cleaning up | 0.000018 | +--------------------------------+----------+ ``` #### 二、`executing` 耗时过高的原因 1. **全表扫描问题** - 未使用合适索引导致 $O(n)$ 复杂度扫描 - 解决方案：`EXPLAIN` 检查执行计划，添加缺失索引 2. **复杂计算瓶颈** ```sql -- 典型高开销操作示例 SELECT SUM(price*quantity) FROM orders WHERE DATE_FORMAT(order_date,'%Y-%m')='2023-08'; -- 函数导致索引失效 ``` 3. **内存操作溢出** - 当出现 `converting HEAP to MyISAM` 或 `Creating tmp table` 时 - 表示内存不足，临时表被写入磁盘（性能下降 10-100 倍）[^5] 4. **锁竞争** - 行锁等待时间会计入 `executing` - 使用 `SHOW ENGINE INNODB STATUS` 检查锁争用 #### 三、优化方法与步骤 **第一步：精确定位瓶颈** ```sql SET profiling = 1; -- 开启 profiling 执行目标SQL; SHOW PROFILE CPU, BLOCK IO FOR QUERY 1; -- 查看详细资源消耗 ``` **第二步：针对性优化策略** | 问题类型 | 优化方案 | 效果预估 | |-------------------|--------------------------------------------------------------------------|----------------| | 全表扫描 | 添加组合索引：`ALTER TABLE t ADD INDEX idx_col1_col2(col1,col2)` | 耗时降为 1/100 | | 内存溢出 | 增大排序缓冲区：`SET sort_buffer_size = 8M;` | 减少磁盘 I/O | | 复杂计算 | 预计算+物化视图：`CREATE MATERIALIZED VIEW mv AS SELECT ...` | 避免实时计算 | | 函数导致索引失效 | 改写查询：`WHERE order_date BETWEEN '2023-08-01' AND '2023-08-31'` | 恢复索引使用 | **第三步：验证优化效果** ```sql -- 对比优化前后指标 FLUSH STATUS; 执行优化后SQL; SHOW SESSION STATUS LIKE 'Handler%'; -- 关键指标解读 Handler_read_first # 全索引扫描次数 ↓ 理想 Handler_read_key # 索引使用次数 ↑ 理想 Handler_read_rnd_next # 全表扫描行数 ↓ 理想 ``` #### 四、高级优化技巧 1. **利用覆盖索引** ```sql -- 原始查询 SELECT id, name FROM users WHERE dept_id=5 ORDER BY join_date; -- 优化方案 ALTER TABLE users ADD INDEX idx_dept_join (dept_id, join_date, name); ``` 2. **批处理替代循环** ```sql -- 低效方式（N+1查询） FOR id IN (SELECT user_id FROM logs) UPDATE users SET last_login=NOW() WHERE id=id; -- 高效批处理 UPDATE users u JOIN logs l ON u.id=l.user_id SET u.last_login=NOW(); ``` 3. **查询重写优化** ```sql -- 原始：多次全表扫描 SELECT * FROM products WHERE price > (SELECT AVG(price) FROM products); -- 优化：单次扫描 SELECT p.* FROM products p JOIN (SELECT AVG(price) avg_price FROM products) tmp ON p.price > tmp.avg_price; ``` > **关键提示**：当 `executing` 阶段伴随 `Sending data` 高耗时时，通常表示网络传输瓶颈，需检查 `max_allowed_packet` 配置[^3][^4]。 --- ### 相关问题 1. 如何通过 `EXPLAIN ANALYZE` 在 MySQL 8 中获取更精确的执行计划？ 2. 当 `show profile` 显示 `Creating sort index` 耗时过高时，有哪些优化手段？ 3. InnoDB 缓冲池命中率如何影响 `executing` 阶段的性能？ 4. MySQL 8 的直方图统计信息如何帮助优化复杂查询的执行效率？ [^1]: MySQL 官方文档 - The SHOW PROFILE Statement [^2]: High Performance MySQL, 4th Edition - Chapter 3. Profiling Server Performance [^3]: MySQL 8.0 Reference Manual - Optimizing SQL Statements [^4]: Percona Blog - Diagnosing MySQL Performance with SHOW PROFILE [^5]: O'Reilly - MySQL Troubleshooting: Identifying I/O Bottlenecks
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值