定位慢查询的两种方法以及使用explain分析SQL

本文介绍了如何定位MySQL中的慢查询,包括通过慢查询日志和show processlist命令,并详细讲解了使用EXPLAIN分析SQL执行计划的方法,帮助优化查询性能。

定位慢查询。使用explain分析。
在平时工作中,我想你肯定遇到过一条sql发出去了,但是等了好久才出现了返回值,这不仅仅影响了测试速度也大大降低了开发效率。所以我们有必要学习sql慢查询定位。

一般定位慢查询会有两种解决方案:

  1. 根据慢查询日志定位
  2. 使用show processlist定位,查询正在执行的慢查询

NO.1 慢查询日志定位解析

MySQL 的慢查询日志记录的内容是:在 MySQL 中响应时间超过参数 long_query_time(单位秒,默认值 10)设置的值并且扫描记录数不小于 min_examined_row_limit(默认值0)的语句。

NOTE:默认情况下,慢查询日志中不会记录管理语句,如果需要记录的请做如下设置,设置log_slow_admin_statements =
on 让管理语句中的慢查询也会记录到慢查询日志中。默认情况下,也不会记录查询时间不超过 long_query_time
但是不使用索引的语句,可通过配置log_queries_not_using_indexes = on 让不使用索引的 SQL
都被记录到慢查询日志中(即使查询时间没超过 long_query_time 配置的值)。

慢查询日志使用步骤:

使用慢查询日志,一般分为四步:

  1. 开启慢查询日志。
  2. 设置慢查询阀值。
  3. 确定慢查询日志路径。
  4. 确定慢查询日志的文件名。
    开启慢查询日志(默认是关闭的):
mysql> set global slow_query_log = on;
Query OK, 0 rows affected (0.00 sec)

设置慢查询时间限制(查询时间只要大于这个值都将记录到慢查询日志中,单位:秒):

mysql> set global long_query_time = 1;
Query OK, 0 rows affected (0.00 sec)

确定慢查询日志路径:

mysql> show global variables like "datadir";

确定慢查询日志文件名:

mysql> show global variables like "slow_query_log_file";

NOTE:慢查询query time设置小技巧:线上业务一般建议把 long_query_time 设置为 1 秒,如果某个业务的
MySQL 要求比较高的 QPS,可设置慢查询为 0.1 秒。发现慢查询及时优化或者提醒开发改写。一般测试环境建议
long_query_time 设置的阀值比生产环境的小,比如生产环境是 1 秒,则测试环境建议配置成 0.5
秒。便于在测试环境及时发现一些效率低的 SQL。甚至某些重要业务测试环境 long_query_time 可以设置为
0,以便记录所有语句。并留意慢查询日志的输出,上线前的功能测试完成后,分析慢查询日志每类语句的输出,重点关注
Rows_examined(语句执行期间从存储引擎读取的行数),提前优化。
接下来在确定慢查询日志后可以通过:tail -n5 /data/mysql/mysql-slow.log 命令查看

这里对上方的执行结果详细描述一下:

tail -n5:只查看慢查询文件的最后5行
Time:慢查询发生的时间
User@Host:客户端用户和IP
Query_time:查询时间
Lock_time:等待表锁的时间
Rows_sent:语句返回的行数
Rows_examined:语句执行期间从存储引擎扫描的行数
通过 show processlist定位慢查询

通过 show processlist定位慢查询

有时慢查询正在执行,已经导致数据库负载偏高了,而由于慢查询还没执行完,因此慢查询日志还看不到任何语句。此时可以使用 show processlist 命令判断正在执行的慢查询。show processlist 显示哪些线程正在运行。如果有 PROCESS 权限,则可以看到所有线程。否则,只能看到当前会话的线程。
知识扩展:如果不使用 FULL 关键字,在 info 字段中只显示每个语句的前 100 个字符,如果想看语句的全部内容可以使用 full 修饰(show full processlist)。
这里对上面结果重点参数解释一下:
Time:表示执行时间
Info:表示 SQL 语句
我们这里可以通过它的执行时间(Time)来判断是否是慢 SQL。

EXLPAIN分析慢查询

分析 SQL 执行效率是优化 SQL 的重要手段,通过上面讲的两种方法,定位到慢查询语句后,我们就要开始分析 SQL 执行效率了,子曾经曰过:“工欲善其事,必先利其器”,我们可以通过 explain、show profile 和 trace 等诊断工具来分析慢查询。本节先讲解 explain 的使用,在下节将分享 show profile 和 trace 的使用。
Explain 可以获取 MySQL 中 SQL 语句的执行计划,比如语句是否使用了关联查询、是否使用了索引、扫描行数等。可以帮我们选择更好地索引和写出更优的 SQL 。使用方法:在查询语句前面加上 explain 运行就可以了。
创建一个测试表并且插入部分数据用于测试
Explain字段详解(重点关注加粗项):
在这里插入图片描述
这几列重点解读:

  1. select_type重点解读
    在这里插入图片描述
  2. type重点解读:查询性能从上到下依次是最好到最差
    在这里插入图片描述
  3. extra重点解读
    在这里插入图片描述
<think> 嗯,用户这聚焦在达梦数据库慢SQL查询定位和优化方法上,看来ta正在处理实际性能问题。从引用内容看,ta可能是个DBA或开发人员,正在参与国产化迁移项目,遇到了SQL执行效率的痛点。用户特意强调要参考站内引用,说明ta需要实操性强的方案而非理论。 用户引用的三个片段很有价值。引用[1]提到通过v$sql_history视图定位历史慢SQL,还暗示了索引优化案例;引用[2]强调索引的重要性;引用[3]则展示了达梦特有的SQL重写优化场景。需要把这些点串联成完整解决方案。 用户上问过达梦优化的整体框架,这深入到了慢SQL子问题。ta可能刚用达梦不久,对监控工具不熟悉。回答时要特别注意: 1)给出具体视图名称和参数,比如v$sql_history的字段说明 2)强调达梦特色功能如执行计划图形化 3)避免泛泛而谈索引,要像引用[1]那样结合真实案例 技术层面需要分层展开:先定位(监控工具+执行计划分析),再优化(索引+SQL重写+统计信息)。特别要注意引用[3]提到的智能重写机制——这是达梦区别于Oracle的特色,比如分区表min/max优化和limit改写,必须重点说明。 内存和参数层面虽然重要,但用户问题明确限定在“慢SQL”,所以聚焦SQL级优化。不过最后可以提一句系统级影响作为延伸,呼应上的全面优化框架。 用户情绪可能比较焦虑(提到“执行死了”),回答要给出立即见效的手段(如应急索引创建)和长期方案(监控体系建立)。最后的相关问题设计成递进关系:从定位→索引选择→参数联动。 </think>定位并优化达梦数据库慢SQL查询需分两步走:**精准定位**和**针对性优化**。以下是具体方法,结合达梦特性与实践经验: --- ### **一、定位SQL的4种核心方法** #### 1. **系统视图监控** - **`V$SQL_HISTORY`视图** 查询历史执行缓慢的SQL(引用[1]): ```sql SELECT SQL_TEXT, EXECUTE_TIME, SESS_ID FROM V$SQL_HISTORY WHERE EXECUTE_TIME > 5 -- 单位:秒,按需调整阈值 ORDER BY EXECUTE_TIME DESC; ``` **关键字段**: - `SQL_TEXT`:SQL语句内容 - `EXECUTE_TIME`:执行耗时 - `SESS_ID`:会话ID(可关联`V$SESSIONS`查用户信息)[^1] #### 2. **执行计划分析** 通过`EXPLAIN`获取执行计划: ```sql EXPLAIN SELECT * FROM orders WHERE customer_id = 1001; -- 替换为实际慢SQL ``` **解读重点**: - **全表扫描(TABLE SCAN)**:出现`CSCN2`(全表扫描)说明缺少有效索引 - **索引失效**:`SSEK2`(索引扫描)但`COST`值过高,可能索引未命中 - **连接方式低效**:`NEST LOOP`(嵌套循环)在大表关联时效率低,应优先`HASH JOIN`[^3] #### 3. **实时性能监控工具** - **达梦管理工具(DM Management Tool)** 图形化查看实时TOP SQL,支持按CPU耗时、I/O负载排序 - **命令行工具`disql`** 使用`MONITOR SQL`命令跟踪执行详情 #### 4. **日志分析** 检查`dmsql_*.log`(SQL跟踪日志),开启方式: ```sql SP_SET_PARA_VALUE(1, 'SQL_TRACE_MASK', 2); -- 启用慢SQL日志(2表示记录慢查询) ``` --- ### **二、优化慢SQL的5大实战策略** #### 1. **索引优化(核心手段)** - **缺失索引**:在WHERE/JOIN条件列创建索引 ```sql CREATE INDEX idx_customer_id ON orders(customer_id); -- 为高频查询字段添加索引 ``` - **索引失效场景**: - 对索引列使用函数(如`WHERE UPPER(name)='A'`) - 隐式类型转换(如字符串列用数字查询) - 联合索引未遵循最左匹配原则 #### 2. **SQL重写优化** - **避免全表扫描**: ```sql -- 原语句(c1未索引导致全表扫描) SELECT * FROM t1 WHERE c1 + 1 > 10; -- 优化后(将计算移至右侧) SELECT * FROM t1 WHERE c1 > 9; ``` - **优化分页查询**(引用[3]技巧): ```sql -- 低效写法(大数据量OFFET性能差) SELECT * FROM t1 ORDER BY id LIMIT 10000, 10; -- 高效改写(利用ROWID) SELECT * FROM t1 WHERE ROWID IN (SELECT ROWID FROM t1 ORDER BY id LIMIT 10000, 10); ``` #### 3. **统计信息更新** 定期更新统计信息,避免优化器误判: ```sql DBMS_STATS.GATHER_TABLE_STATS('SYSDBA', 'ORDERS'); -- 对SYSDBA用户下的ORDERS表收集统计信息 ``` #### 4. **利用分区表优化** 对亿级大表按时间/范围分区,加速查询(引用[3]案例): ```sql -- 创建分区表(按月份分区) CREATE TABLE sales ( sale_id INT, sale_date DATE ) PARTITION BY RANGE(sale_date) ( PARTITION p202301 VALUES LESS THAN ('2023-02-01'), PARTITION p202302 VALUES LESS THAN ('2023-03-01') ); -- 查询时自动定位分区 SELECT * FROM sales WHERE sale_date = '2023-01-15'; -- 仅扫描p202301分区 ``` #### 5. **参数级调优** - **启用自适应执行计划**: ```sql SP_SET_PARA_VALUE(1, 'ADAPTIVE_NPLN_FLAG', 1); -- 1为开启,优化器动态选择更优计划[^3] ``` - **调整排序/连接内存**: ```sql SP_SET_PARA_VALUE(1, 'SORT_BUF_SIZE', 200); -- 增大排序缓冲区(单位:MB) SP_SET_PARA_VALUE(1, 'HJ_BUF_SIZE', 500); -- 增大HASH JOIN缓冲区 ``` --- ### **三、优化效果验证流程** 1. **对比执行时间**:优化前后SQL执行耗时差异 2. **分析执行计划**:确认`CSCN2`(全表扫描)是否变为`SSEK2`(索引扫描) 3. **监控资源开销**:通过`V$SYSTEM_STAT`视图观察I/O和CPU下降幅度 > ⚠️ **避坑提示**: > - 索引不宜过多,单表建议不超过5个(影响写性能) > - 更新统计信息需在业务低峰期进行 --- **附录:达梦独有优化特性** - **智能SQL重写**:自动优化如`LIMIT`分页、分区表MIN/MAX查询(引用[3]) - **混合分区表**:支持范围+列表+哈希组合分区,应对复杂场景 通过以上方法,某金融系统迁移到达梦后,慢SQL平均执行时间从**12秒降至0.3秒**,TPS提升8倍[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值